Syndiquer le contenu
Mis à jour : il y a 9 heures 25 min

Nix pour les développeurs

6 juillet, 2017 - 11:32

Nix est un gestionnaire de paquets « fonctionnel » (basé sur des fonctions, sans effet de bord). Cette caractéristique apporte des avantages indéniables, notamment de pouvoir mettre en place des environnements logiciels isolés, reproductibles et composables. Ceci peut être très utile à un administrateur système mais également à un développeur.

On trouve pas mal d’informations sur l’écosystème Nix et son utilisation, ainsi que des retours d’expérience des utilisateurs. En revanche, les documents à destination des développeurs sont moins nombreux et se limitent souvent à l’utilisation ou à la mise en place d’environnements de développement simples.

Cet article a pour objectif d’illustrer l’intérêt de Nix pour un développeur dans des cas simples et « un peu moins simples ». Pour cela, il se base sur un projet d’exemple en C++ et en Python, mais Nix peut également être utilisé pour d’autres langages. Je ne suis pas un expert en Nix, donc n’hésitez pas à proposer vos remarques ou améliorations dans les commentaires ou sur le dépôt GitHub du projet d’exemple.

Sommaire Introduction Exemple 1 : créer un environnement de développement de test Scénario

Vous avez codé un script Python myscript.py et vous voulez le tester dans un environnement vierge.

# myscript.py import numpy x = numpy.ndarray(42, int) x[0::2] = 13 x[1::2] = 37 print(x) Avec les outils classiques (Python, virtualenv, pip) virtualenv -p /usr/bin/python3 --no-site-packages ~/myvenv source ~/myvenv/bin/activate pip install numpy python myscript.py deactivate rm -rf ~/myvenv Avec Nix nix-shell --pure -p python35Packages.numpy --run "python myscript.py" Exemple 2 : reproduire un environnement de développement Scénario

Vous développez un logiciel myprog en C++, compilé avec Cmake et utilisant la bibliothèque Boost. Vous avez récupéré votre projet sur une nouvelle machine et voulez le compiler.

Avec les outils classiques (par exemple sous Arch Linux) sudo pacman -S gcc cmake boost mkdir build cd build cmake .. make Avec Nix

Au cours du projet, un fichier default.nix est tenu à jour (il indique notamment les dépendances à Cmake et à Boost). Il suffit alors de lancer la commande :

nix-build Exemple 3 : empaqueter un projet Scénario

Le projet myprog de l’exemple précédent vient d’aboutir à une version 0.1 dont le code source est disponible en ligne. Vous voulez l’installer proprement sur votre système.

Avec les outils classiques (par exemple sous Arch Linux) sudo pacman -S base-devel mkdir myprog cd myprog # Écrire un fichier PKGBUILD (avec l’adresse URL de la publication, les dépendances, les instructions de compilation, etc.). makepkg sudo pacman -U myprog-0.1-1-any.pkg.tar.xz

Cette solution fonctionne pour Arch Linux uniquement. Si vous voulez une solution pour Debian ou Fedora, il faut créer les paquets Deb ou RPM correspondants.

Avec Nix cp default.nix release.nix # dans le fichier release.nix, changer la valeur de la variable src par l’URL de la publication nix-env -f release.nix -i myprog

Ici, la solution devrait fonctionner automatiquement pour tout système compatible avec Nix (Arch Linux, Debian, Fedora…).

Exemple 4 : personnaliser des dépendances Scénario

Vous développez des logiciels de traitement d’images utilisant la bibliothèque OpenCV. Pour cela, vous utilisez le paquet OpenCV fourni par la logithèque système. Un de vos logiciels doit utiliser GTK ; malheureusement, le paquet OpenCV a été compilé avec l’option -DWITH_GTK=OFF.

Avec les outils classiques

Bienvenue en enfer… Quelques « solutions » classiques :

  • recompiler OpenCV à partir du code source ; vous pourrez ensuite faire une installation système (mais cela peut impacter les autres logiciels) ou une installation locale (mais il faudra configurer les chemins vers votre OpenCV personnalisé quand vous en aurez besoin) ;
  • utiliser un système d’environnement virtualisé (chroot, Flatpak, Docker…). Pour cela, vous devrez mettre en place le système, puis récupérer une image d’OpenCV compilé avec les bonnes options ou créer votre propre image.
Avec Nix

Les paquets Nix sont paramétrables. Ainsi pour activer l’option GTK 2 du paquet OpenCV, il suffit (presque) d’ajouter la ligne suivante dans le fichier default.nix. La recompilation et la gestion des différentes versions est automatique.

opencv3gtk = pkgs.opencv3.override { enableGtk2 = true; }; Quelques rappels sur Nix Présentation

Nix est un gestionnaire de paquets fonctionnel. Le terme « fonctionnel » est à prendre au sens mathématique : une fonction prend des entrées et produit une sortie, sans réaliser d’effets de bord. Ceci permet de créer des environnements logiciels (compilation, installation et configuration) avec les avantages suivants :

  • les environnements sont reproductibles ;
  • ils sont paramétrables et composables ;
  • ils n’ont jamais besoin d’être dupliqués ;
  • ils sont exécutés nativement.

L’écosystème Nix comporte différents éléments :

  • un langage permettant de décrire un environnement logiciel (appelé nix-expression) ;
  • des outils (nix-build, nix-env, nix-shell…) permettant de construire, installer, exécuter, etc., des nix-expressions ;
  • un dépôt officiel (nixpkgs) de nix-expressions…

Il existe une distribution GNU/Linux (NixOS) directement basée sur ces éléments, mais le système Nix peut être installé sur un système d’exploitation quelconque (GNU/Linux, BSD, macOS) pour y servir de logithèque et de système d’environnement virtuel.

Enfin, Nix a inspiré un système concurrent, nommé GNU Guix. Tout comme Nix, Guix peut être utilisé sur un système d’exploitation classique ou via une distribution dédiée, GuixSD. À la différence de Nix, Guix est basé sur un langage existant (Guile Scheme) et accorde une plus grande importance à l’aspect « logiciel libre ».

Quelques commandes Nix
  • voir les paquets installés :
nix-env -q
  • voir les paquets disponibles contenant le motif "firefox" :
nix-env -qa 'firefox'
  • installer le paquet firefox :
nix-env -i firefox
  • désinstaller le paquet firefox :
nix-env -e firefox

Toutes ces commandes sont utilisables avec les droits utilisateurs et dans l’environnement de l’utilisateur. Les paquets sont gérés par un service (nix-daemon) qui les installe dans un répertoire commun /nix/store et les rend disponibles aux différents utilisateurs.

Projet d’exemple (C++/Python)

Pour illustrer l’utilisation de Nix, on considère un projet type (the_checkerboard_project) qui calcule et affiche des images de damier.

Ce projet est composé d’une bibliothèque C++ (checkerboard) et d’une interface Python (pycheckerboard) contenant la liaison proprement dite et un script Python additionnel.

the_checkerboard_project/ ├── checkerboard │ ├── CMakeLists.txt │ ├── checkerboard.cpp │ ├── checkerboard.hpp │ └── test_checkerboard.cpp └── pycheckerboard ├── setup.py └── src ├── checkerboard │ └── binding.cpp └── pycheckerboard ├── __init__.py └── test1.py

Les fonctions pour calculer un damier et pour afficher une image, en utilisant la bibliothèque OpenCV. La compilation est réalisée via Cmake, qui fait le lien avec OpenCV et qui construit la bibliothèque checkerboard et un exécutable de test.

# checkerboard/CMakeLists.txt cmake_minimum_required( VERSION 3.0 ) project( checkerboard ) # lien avec OpenCV find_package( PkgConfig REQUIRED ) pkg_check_modules( MYPKG REQUIRED opencv ) include_directories( ${MYPKG_INCLUDE_DIRS} ) # bibliothèque checkerboard add_library( checkerboard SHARED checkerboard.cpp ) target_link_libraries( checkerboard ${MYPKG_LIBRARIES} ) install( TARGETS checkerboard DESTINATION lib ) install( FILES checkerboard.hpp DESTINATION "include" ) # exécutable de test add_executable( test_checkerboard test_checkerboard.cpp ) target_link_libraries( test_checkerboard checkerboard ${MYPKG_LIBRARIES} ) install( TARGETS test_checkerboard DESTINATION bin )

L’interface Python est faite avec Boost Python. La liaison (binding.cpp) expose simplement les deux fonctions de la bibliothèque checkerboard. Un script additionnel (test1.py) fournit une fonction et un programme de test. Le tout est compilé dans un paquet Python en utilisant un script setuptools/pip très classique.

# pycheckerboard/setup.py from setuptools import setup, Extension checkerboard_module = Extension('checkerboard_binding', sources = ['src/checkerboard/binding.cpp'], libraries = ['checkerboard', 'boost_python', 'opencv_core', 'opencv_highgui']) setup(name = 'pycheckerboard', version = '0.1', package_dir = {'': 'src'}, packages = ['pycheckerboard'], python_requires = '<3', ext_modules = [checkerboard_module]) Configuration Nix basique

Classiquement (sans Nix), on exécuterait les commandes suivantes pour compiler et installer la bibliothèque checkerboard :

mkdir checkerboard/build cd checkerboard/build cmake .. make sudo make install

Nix permet d’exécuter ces commandes automatiquement. Pour cela, il suffit d’écrire un fichier de configuration default.nix indiquant le nom du paquet, le chemin vers le code source et les dépendances (voir cette dépêche sur l’anatomie d’une dérivation Nix).

# checkerboard/default.nix with import <nixpkgs> {}; with pkgs; stdenv.mkDerivation { name = "checkerboard"; src = ./.; buildInputs = [ cmake pkgconfig opencv3 ]; }

Les dépendances spécifiées ici seront installées automatiquement par Nix, si besoin. Ici la dépendance à Cmake implique que la compilation sera réalisée avec Cmake (cf. les commandes précédentes). La compilation et l‘installation de la bibliothèque checkerboard peuvent alors être lancées avec la commande :

nix-env -f . -i checkerboard

La bibliothèque ainsi que l’exécutable de test sont alors disponibles dans les chemins système, ou plus exactement dans les chemins système vus par l’utilisateur. Cependant, il n’est pas obligatoire d’installer le paquet checkerboard. On peut simplement lancer un shell dans un environnement virtuel contenant le paquet :

nix-shell

Ce mécanisme de shell virtuel propose des fonctionnalités très utiles. Par exemple, partir d’un environnement vierge et exécuter juste une commande dans cet environnement :

nix-shell --pure --run test_checkerboard Configuration Nix modulaire

Au lieu de proposer un paquet complet, on peut découper notre nix-expression (default.nix) en plusieurs modules, appelés dérivations, qui pourront alors être réutilisés ou reparamétrés. Par exemple, pour créer une dérivation opencv3gtk et une dérivation checkerboard :

# checkerboard/default.nix { system ? builtins.currentSystem }: let pkgs = import <nixpkgs> { inherit system; }; in with pkgs; stdenv.mkDerivation rec { opencv3gtk = import ./opencv3gtk.nix { inherit (pkgs) opencv3; }; checkerboard = import ./checkerboard.nix { inherit opencv3gtk; inherit (pkgs) cmake pkgconfig stdenv; }; }

Ces deux dérivations sont implémentées dans des fichiers spécifiques, pour faciliter leur réutilisation. Par exemple, pour checkerboard :

# checkerboard/checkerboard.nix { cmake, opencv3gtk, pkgconfig, stdenv }: stdenv.mkDerivation { name = "checkerboard"; src = ./.; buildInputs = [ cmake opencv3gtk pkgconfig ]; }

Ici, la deuxième ligne indique les paramètres du paquet (c’est‐à‐dire les dépendances à utiliser pour Cmake, pkgconfig, etc.). Ce mécanisme permet de composer les paquets de façon très puissante. Par exemple, on peut reparamétrer le paquet OpenCV en activant la prise en charge de GTK (qui n’est pas activée par défaut) et composer ce nouveau paquet à notre paquet checkerboard, qui disposera alors des fonctionnalités GTK. On peut même modifier finement les options de compilation du paquet OpenCV (par exemple, désactiver les en‐têtes pré‐compilés qui consomment beaucoup de mémoire vive) :

# checkerboard/opencv3gtk.nix { opencv3 }: let opencv3gtk = opencv3.override { enableGtk2 = true; }; in opencv3gtk.overrideDerivation ( attrs: { cmakeFlags = [attrs.cmakeFlags "-DENABLE_PRECOMPILED_HEADERS=OFF"]; } )

Bien entendu, reparamétrer un paquet nécessite une recompilation si le paquet n’a pas déjà été compilé pour ce jeu de paramètres.

Notez que le nouveau default.nix ne contient pas de dérivation par défaut. Il faut donc préciser la dérivation à utiliser ou à installer :

nix-shell -A checkerboard nix-env -f . -iA checkerboard Configuration Nix pour un paquet Python

De nombreux langages proposent leur propre système de gestion de paquets (pip pour Python, gem pour Ruby, npm pour JavaScript, etc.). Nix fournit des fonctionnalités pour créer ce genre de paquets.

Par exemple, pour créer un paquet Python de notre projet, on peut écrire un fichier default.nix, qui va réutiliser les dérivations opencv3gtk et checkerboard précédentes. Nix fournit une fonction buildPythonPackage qui permet de créer simplement un paquet Python en utilisant le script setuptools/pip :

# pycheckerboard/default.nix { system ? builtins.currentSystem }: let pkgs = import <nixpkgs> { inherit system; }; opencv3gtk = import ../checkerboard/opencv3gtk.nix { inherit (pkgs) opencv3; }; checkerboard = import ../checkerboard/checkerboard.nix { inherit opencv3gtk; inherit (pkgs) cmake pkgconfig stdenv; }; in with pkgs; pythonPackages.buildPythonPackage { name = "pycheckerboard"; src = ./.; buildInputs = [ checkerboard python27Packages.boost opencv3gtk ]; }

Comme pour la bibliothèque, on peut alors installer la dérivation ou la tester interactivement dans un shell virtuel. Les dépendances opencv3gtk et checkerboard correspondent aux dérivations de la section précédente et ne seront pas recompilées ni dupliquées.

$ cd pycheckerboard $ nix-shell --pure --run python Obtaining file:///home/nokomprendo/the_checkerboard_project/pycheckerboard Installing collected packages: pycheckerboard ... Python 2.7.13 (default, Dec 17 2016, 20:05:07) >>> import pycheckerboard.test1 as pt >>> pt.test1() running test1.py... Conclusion

Nix permet de définir des environnements logiciels reproductibles, paramétrables et composables. Il suffit d’écrire quelques fichiers .nix qui viennent compléter les outils de compilation classiques du projet. Les paquets ainsi créés peuvent ensuite être installés ou exécutés, éventuellement dans un environnement isolé. Nix gère automatiquement la compilation, les dépendances et les différentes versions de paquets. Ces fonctionnalités sont intéressantes pour un développeur, car elles permettent non seulement de simplifier le déploiement, mais également d’offrir un environnement de développement multi‐langage léger et reproductible.

Télécharger ce contenu au format Epub

Lire les commentaires

Qui est le coupable ? Le processeur ! Retour sur un bogue important des SkyLake & Kaby Lake Intel

6 juillet, 2017 - 11:29

Certains d’entre vous ont peut‐être vu passer l’information : les derniers processeurs Intel des familles Skylake et Kaby Lake sont victimes d’un bogue lorsque l’hyper‐threading est activé. On trouve par exemple un article sur Ars Technica, et Debian propose des instructions détaillées pour corriger le problème en mettant à jour le microcode (firmware) du processeur.

Cette dépêche propose revenir sur les événements qui ont mené à la découverte du problème. Xavier Leroy le décrit en détail dans un article sur le blog de l’équipe Gallium, dont je proposerai un résumé pour les lecteurs francophones.

Tout commence en avril 2016 lorsqu’un SIOU (Serious Industrial OCaml User), comme il les appelle, le contacte en privé pour lui signaler un bogue dans un de leur logiciel : ce dernier subit des erreurs de segmentation de manière aléatoire après un certain temps. Il n’arrive pas à reproduire le bogue sur sa propre machine et le côté aléatoire du bogue lui fait soupçonner un problème matériel chez le client (mémoire vive défectueuse, surchauffe…). Il leur propose de tester leur mémoire et de désactiver l’hyper‐threading. La mémoire était bonne, mais il ne teste pas la désactivation (ce qui aurait résolu le problème).

De son côté, le client fait ses tests et aboutit aux résultats suivants : le bogue est présent avec la version 4.03 mais pas la 4.02.3 du compilateur OCaml, avec GCC mais pas Clang (l’environnement d’exécution d’OCaml est en C), sur GNU/Linux et Windows mais pas macOS (ce qui se comprend, ce dernier utilisant Clang). Les coupables semblent identifiés : OCaml 4.03 et GCC, et le client suppose qu’il y a une erreur dans le code C de l’environnement d’exécution d’OCaml.

Début mai 2016, le client offre un accès à sa machine à Xavier Leroy pour qu’il puisse identifier le problème. Il analyse des vidages mémoire (dumps) post‐plantage, voit bien des problèmes avec le ramasse‐miettes, mais ne comprend pas ce qui peut causer un tel comportement dans son code. Il fait alors des tests en lançant le programme en parallèle (1, 2, 4, 8 ou 16 instances) et, là, tout devient clair : pas de bogue quand l’hyper‐threading n’est pas utilisé. Ils font des tests en le désactivant dans le BIOS et le problème ne se manifeste plus.

Cela aurait pu en rester là : le client était satisfait de pouvoir utiliser une version de l’environnement d’exécution avec Clang, et Xavier Leroy ne sachant pas comment signaler le problème à Intel en reste là. Mais, début 2017, un autre SIOU fait un rapport de bogue sur le système de suivi d’OCaml. Les symptômes étaient similaires et la discussion sur le ticket fut la suivante :

  • douze heures après l’ouverture, une des ingénieurs précise que tous les ordinateurs qui ont pu reproduire le bogue ont un processeur de la famille Skylake ;
  • le lendemain, Xavier Leroy signale son expérience passée et propose de désactiver l’hyper‐threading ;
  • le jour suivant, un autre ingénieur du SIOU rapporte qu’en désactivant l’hyper‐threading le problème disparaît ;
  • en parallèle, il constate que si l’environnement d’exécution est compilé avec gcc -O1 et non gcc -O2 alors le bogue disparaît. Ce qui permet de comprendre pourquoi cela apparaît avec la version 4.03, qui est celle inaugurant l’option -O2 par défaut pour l’environnement d’exécution ;
  • Mark Shinwell contacte des collègues chez Intel et s’occupe de rapporter le problème au support client d’Intel.

Enfin, cinq mois plus tard, Debian publie une mise à jour du microcode des processeurs Intel et Intel publie, en avril, une mise à jour des spécifications de la 6e génération de ses processeurs. On trouve à la page 65 de ce document une mention du problème SKL150 qui était à l’origine de tous ces bogues, présenté en ces termes chez Debian :

SKL150 - Short loops using both the AH/BH/CH/DH registers and
the corresponding wide register may result in unpredictable
system behavior. Requires both logical processors of the same
core (i.e. sibling hyperthreads) to be active to trigger, as
well as a “complex set of micro‐architectural conditions”.

Pour ceux que cela intéresse et qui comprennent l’assembleur (ce qui n’est pas mon cas), le problème venait de ce bout de code du ramasse‐miettes d’OCaml :

hd = Hd_hp (hp); /*...*/ Hd_hp (hp) = Whitehd_hd (hd);

Qui après expansion des macros donne :

hd = *hp; /*...*/ *hp = hd & ~0x300;

Avec Clang, cela donnait :

movq (%rbx), %rax [...] andq $-769, %rax # imm = 0xFFFFFFFFFFFFFCFF movq %rax, (%rbx)

Tandis que le code optimisé de GCC donnait :

movq (%rdi), %rax [...] andb $252, %ah movq %rax, (%rdi)

Qui pouvait lever le bogue du processeur s’il se trouvait dans une petite boucle ?

Ce bogue sur ces processeurs impacte tous les systèmes d’exploitation. Le correctif du microcode pour la génération Skylake existe donc depuis avril, car Intel distribue ses mises à jour à toutes et tous, permettant aux mainteneurs des distributions de réaliser l’empaquetage afin de les rendre disponibles.

Cependant, il n’en va pas de même pour la génération Kaby Lake, pour laquelle Intel ne distribue ses correctifs de microcodes qu’aux seuls constructeurs ou assembleurs. Il résulte de cette situation une grande disparité des disponibilités pour cette mise à jour : certains constructeurs l’ont déjà proposée, d’autres ne le font pas.

Au final, il semblerait que Skylake se soit transformé en Skyfall et que la légendaire crainte gauloise que le ciel leur tombe sur la tête était fondée ! :-D

Télécharger ce contenu au format Epub

Lire les commentaires

La bière libre, ColiBibine, est de retour pour les RMLL !

5 juillet, 2017 - 13:57

La bière libre des étudiants de la licence CoLibre de l’Université Lyon 2 est de retour à l’occasion des Rencontres mondiales du logiciel libre 2017 (RMLL) à Saint‐Étienne.

Projet brassé et porté par l’association des étudiants du diplôme, la nouvelle CoLiBibine « tout grain » garde les mêmes principes à savoir :

  • approfondir la culture des logiciels libres et leurs quatre libertés fondamentales : exécuter, étudier, modifier, diffuser ;
  • permettre aux étudiants à apprendre à construire et porter un projet ;
  • soutenir les initiatives étudiantes ;
  • faire quelque chose de sympa et ensuite en faire profiter les autres (et non, non, nous n’allons pas tout boire !).

Soutenue par l’ALDIL, cette campagne permettra de financer les projets des étudiants de la licence Colibre en vous donnant l’occasion de goûter à leur bière libre !

Une première distribution a lieu aux RMLL dans le village associatif sur le stand CoLibre. D’autres points de retrait « Retire ta bière » sont à disposition sur Lyon afin de pouvoir récupérer sa CoLiBibine après les RMLL.

Les ingrédients de la CoLibibine « tout grain » ?
  • malt (cara blond 20ebc & cara ruby 50ebc), houblon pacific jade, extrait de malt (pale & ambré), levure, eau, sucre, jus de créativité, passion, bonne humeur, beaucoup d’amour, joie, quelques plumes de colibris, et puis c’est tout… (Forkez notre recette)
  • et votre participation à ce projet permettant de soutenir et de développer l’association CoLibreAsso.
Prochain brassage : la cuvée spéciale RMLL 2017 : bière camp

Nous avons prévu de brasser une nouvelle cuvée, à la rentrée. Vous aurez l’occasion donc de pouvoir choisir ses ingrédients pour créer la cuvée RMLL 2017. Vous serez prochainement invités à participer à notre bière Camp via notre sondage.

Alors, à vos décapsuleurs !

NdM : l’abus d’alcool est dangereux pour la santé. À consommer avec modération (et avec la modération aussi si possible).

Télécharger ce contenu au format Epub

Lire les commentaires

Multiseat avec des pilotes libres, non libres et systemd

5 juillet, 2017 - 13:17

Ou comment avoir deux utilisateurs simultanés sur un seul PC, avec deux écrans, deux clavier, deux souris et deux cartes graphiques (et deux chaises !), facilement et pour pas cher.

    Sommaire

    J’ai deux cartes graphiques : une NVIDIA GTX 750 Ti et une Radeon FirePro V3700. Problème : je veux utiliser les pilotes non libres NVIDIA (pour des meilleures performances). C‘était impossible jusqu’à la sortie (et mise à jour) de Fedora 25.
    Cette nouvelle version utilise la fonctionnalité GLVND qui permet de faire cohabiter deux pilotes OpenGL. Mes deux cartes graphiques peuvent désormais cohabiter sans avoir à utiliser uniquement les pilotes Mesa 3D (nouveau et radeon) pour les deux processeurs graphiques.

    Prérequis

    Au fil de vos essais, vous vous retrouverez peut‐être avec un système incapable de lancer une session graphique, ou même l’accès à la console sera impossible (peu probable). Je vous conseille d’installer un accès à distance SSH avant de vous lancer. Testez‐le avant et, si vous n’avez pas de deuxième ordinateur, des clients SSH sont disponibles pour les appareils mobiles sous Android et iOS.

    Fedora 25 utilise systemd comme système d’initialisation et implémente logind. Ce composant permet de gérer les sessions, les utilisateur connectés et les sièges (seat). Pour configurer plusieurs « sièges » sur un seul système, on peut utiliser logind qui automatise tout au lieu d’avoir à éditer à la main un fichier Xorg.conf !
    J’ai un système multi‐seat fonctionnel sous Fedora 25, cependant Debian 9 Stretch est peut‐être compilé avec GLVND. Si vous avez deux cartes graphiques identiques, vous pouvez utiliser n’importe quelles distributions pour peu qu’elle fonctionne avec systemd.

    Matériel requis

    Vous pouvez utiliser n’importe quel périphérique USB ou PS/2, mais essayez d’avoir une configuration logique (brancher l’écran avec la plus grande définition sur la carte graphique la plus puissante si vous souhaitez faire du jeu vidéo).
    Pour une expérience optimale, il est préférable d’avoir une carte son par utilisateur (et un ou deux casques audio pour éviter la cacophonie), sinon il est possible de configurer pulseaudio pour deux utilisateurs (non testé). Vous pouvez utiliser les sorties son HDMI de votre écran, ce, même si cet écran est utilisé pour un autre poste.
    Il est conseillé d’utiliser des périphériques USB de marques et modèles différents, comme ça leurs identificateurs USB seront différents (apparemment les périphériques USB ont tendance à s’échanger leur place).

    Configuration

    C’est très facile, mais après, bonne chance pour vous y retrouver avec tous les câbles ! Je vous conseille aussi de brancher les écrans aux cartes graphiques dès le début.

    Logiciels

    Tout d’abord, trouvez quel gestionnaire de sessions (desktop manager) vous utilisez (c’est ce qui crée l’écran de connexion). Si c’est GDM (pour GNOME), SDDM (pour Plasma 5), il va falloir changer, car ceux‐ci n’afficheront un écran de connexion que sur le premier siège. Je conseille LightDM, bien que XDM soit compatible multi‐seat :

    • installez LightDM : # dnf install lightdm ;
    • installez le thème de votre choix (greeter) : # dnf install slick-greeter (ou lightdm-gtk, lightdm-kde…) ;
    • désinstallez votre gestionnaire de sessions : # dnf remove gdm ;
    • redémarrez ou passez en console (Ctrl + Alt + F2) et relancez les services : # systemctl stop gdm, puis # systemclt start lightdm.
    Matériel Identifiez

    Ensuite, listez votre matériel, qui est par défaut entièrement alloué au siège initial seat0 : loginctl seat-status. Exemple (je liste deux sièges, car j’ai déjà assigné mon matériel ; si vous commencez vous n'aurez que seat0) :

    $ loginctl seat-status seat0 seat1--no-pager
    seat0
    Sessions: *2
    Devices:
    ├─/sys/devices/LNXSYSTM:00/LNXPWRBN:00/input/input2
    │ input:input2 "Power Button"
    ├─/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input8
    │ input:input8 "Video Bus"
    ├─/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0
    │ input:input0 "Power Button"
    ├─/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/input/input1
    │ input:input1 "Sleep Button"
    ├─/sys/devices/pci0000:00/0000:00:02.0/drm/card0
    │ [MASTER] drm:card0
    │ ├─/sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-HDMI-A-1
    │ │ [MASTER] drm:card0-HDMI-A-1
    │ └─/sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-VGA-1
    │ [MASTER] drm:card0-VGA-1
    ├─/sys/devices/pci0000:00/0000:00:02.0/drm/renderD128
    │ drm:renderD128
    ├─/sys/devices/pci0000:00/0000:00:02.0/graphics/fb2
    │ [MASTER] graphics:fb2 "inteldrmfb"
    ├─/sys/devices/pci0000:00/0000:00:03.0/sound/card0
    │ sound:card0 "HDMI"
    │ ├─/sys/devices/pci0000:00/0000:00:03.0/sound/card0/input14
    │ │ input:input14 "HDA Intel HDMI HDMI/DP,pcm=3"
    │ ├─/sys/devices/pci0000:00/0000:00:03.0/sound/card0/input15
    │ │ input:input15 "HDA Intel HDMI HDMI/DP,pcm=7"
    │ ├─/sys/devices/pci0000:00/0000:00:03.0/sound/card0/input16
    │ │ input:input16 "HDA Intel HDMI HDMI/DP,pcm=8"
    │ ├─/sys/devices/pci0000:00/0000:00:03.0/sound/card0/input17
    │ │ input:input17 "HDA Intel HDMI HDMI/DP,pcm=9"
    │ └─/sys/devices/pci0000:00/0000:00:03.0/sound/card0/input18
    │ input:input18 "HDA Intel HDMI HDMI/DP,pcm=10"
    ├─/sys/devices/pci0000:00/0000:00:14.0/usb3
    │ usb:usb3
    │ ├─/sys/devices/pci0000:00/0000:00:14.0/usb3/3-3/3-3:1.0/0003:046D:C05A.0002/input/input5
    │ │ input:input5 "Logitech USB Optical Mouse"
    │ └─/sys/devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.1/0003:0603:00F2.0004/input/input7
    │ input:input7 "NOVATEK USB Keyboard"
    ├─/sys/devices/pci0000:00/0000:00:14.0/usb4
    │ usb:usb4
    ├─/sys/devices/pci0000:00/0000:00:1a.0/usb1
    │ usb:usb1
    │ └─/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1
    │ usb:1-1
    ├─/sys/devices/pci0000:00/0000:00:1b.0/sound/card1
    │ sound:card1 "PCH"
    │ ├─/sys/devices/pci0000:00/0000:00:1b.0/sound/card1/input10
    │ │ input:input10 "HDA Intel PCH Rear Mic"
    │ ├─/sys/devices/pci0000:00/0000:00:1b.0/sound/card1/input11
    │ │ input:input11 "HDA Intel PCH Line"
    │ ├─/sys/devices/pci0000:00/0000:00:1b.0/sound/card1/input12
    │ │ input:input12 "HDA Intel PCH Line Out"
    │ ├─/sys/devices/pci0000:00/0000:00:1b.0/sound/card1/input13
    │ │ input:input13 "HDA Intel PCH Front Headphone"
    │ └─/sys/devices/pci0000:00/0000:00:1b.0/sound/card1/input9
    │ input:input9 "HDA Intel PCH Front Mic"
    ├─/sys/devices/pci0000:00/0000:00:1c.4/0000:06:00.0/drm/card2
    │ [MASTER] drm:card2
    ├─/sys/devices/pci0000:00/0000:00:1c.4/0000:06:00.0/drm/renderD130
    │ drm:renderD130
    ├─/sys/devices/pci0000:00/0000:00:1c.4/0000:06:00.1/sound/card2
    │ sound:card2 "NVidia"
    │ ├─/sys/devices/pci0000:00/0000:00:1c.4/0000:06:00.1/sound/card2/input19
    │ │ input:input19 "HDA NVidia HDMI/DP,pcm=3"
    │ ├─/sys/devices/pci0000:00/0000:00:1c.4/0000:06:00.1/sound/card2/input20
    │ │ input:input20 "HDA NVidia HDMI/DP,pcm=7"
    │ ├─/sys/devices/pci0000:00/0000:00:1c.4/0000:06:00.1/sound/card2/input21
    │ │ input:input21 "HDA NVidia HDMI/DP,pcm=8"
    │ └─/sys/devices/pci0000:00/0000:00:1c.4/0000:06:00.1/sound/card2/input22
    │ input:input22 "HDA NVidia HDMI/DP,pcm=9"
    ├─/sys/devices/pci0000:00/0000:00:1d.0/usb2
    │ usb:usb2
    │ └─/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1
    │ usb:2-1
    ├─/sys/devices/platform/efi-framebuffer.0/graphics/fb0
    │ [MASTER] graphics:fb0 "EFI VGA"
    ├─/sys/devices/platform/i8042/serio0/input/input3
    │ input:input3 "AT Translated Set 2 keyboard"
    └─/sys/devices/virtual/misc/rfkill
    misc:rfkill

    seat1
    Sessions: *c1
    Devices:
    ├─/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card1
    │ [MASTER] drm:card1
    │ ├─/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card1/card1-DVI-I-1
    │ │ [MASTER] drm:card1-DVI-I-1
    │ └─/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card1/card1-DVI-I-2
    │ [MASTER] drm:card1-DVI-I-2
    ├─/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/renderD129
    │ drm:renderD129
    ├─/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/graphics/fb1
    │ [MASTER] graphics:fb1 "radeondrmfb"
    ├─/sys/devices/pci0000:00/0000:00:14.0/usb3/3-1/3-1:1.0/0003:413C:3200.0001/input/input4
    │ input:input4 "Dell Dell USB Mouse"
    └─/sys/devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.0/0003:0603:00F2.0003/input/input6
    input:input6 "NOVATEK USB Keyboard"

    Il y a trois catégories qui vous intéressent : drm (carte graphique), graphics (framebuffer et écran) et input (clavier et souris). Notez ici que j’ai un iGPU Intel non utilisé, et que, faute aux pilotes NVIDIA, mon système utilise les framebuffers au lieu de l’interface moderne DRM (donc, pas de Wayland ici).
    Il vous faut donner à un siège :

    • un entrée clavier input:inputX ;
    • une entrée souris input:inputX ;
    • une carte graphique drm:cardX ;
    • un processeur graphique drm:renderXXX ;
    • un framebuffer (graphics:fbX _nom_du_pilote_).

    Pour identifier vos périphériques, référez‐vous à leur marque (Logitech USB Optical Mouse est une souris Dell par exemple…).

    Assignez

    Sélectionnez le chemin d’accès entier du périphérique (attention, ça peut dépasser de votre terminal), et collez‐le dans la commande suivante : # loginctl attach seatX chemin_du_matériel où X représente l’identifiant du siège (vous pouvez mettre 1, 2, A, B…).
    Par exemple, pour assigner mon clavier USB au siège 2, je tape
    sudo loginctl attach seat1 /sys/devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.0/0003:0603:00F2.0003/input/input6.
    Si certaines touches de votre clavier ne fonctionnent pas (touches multimédias ou Windows, pavé numérique…), regardez si votre clavier n’est pas listé deux fois (deux lignes input:inputX avec le même nom), et rajoutez le second input au siège concerné.

    Utilisez

    Si un écran de connexion n’est pas apparu sur le(s) nouveau(x) siège(s), redémarrez votre gestionnaire de sessions ou votre système si vous êtes flemmard.
    systemctl restart lightdm (notez que cette commande fermera instantanément toute session graphique, donc sauvegardez vos documents ouverts).

    Post‐scriptum:

    Les ressources de votre système seront partagées entre les utilisateurs, donc il est préférable d’avoir un processeur multicœur, un disque dur rapide et suffisamment de mémoire vive (les environnements de bureau seront chargés plusieurs fois…). Si votre machine dispose de peu de ressources, envisagez de passer à XFCE au lieu de GNOME ou KDE. Vous pouvez aussi mettre le /home de chaque utilisateur sur un disque différent, ou encore mettre en place un RAID logiciel ou matériel si vous avez le matériel nécessaire. Pour le réseau, comme d’habitude, votre interface sera partagée entre les utilisateurs, alors attention aux téléchargements volumineux (comme dans le cas de plusieurs ordinateurs se partageant la connexion Internet d’une box).
    Pour la vie privée, l’autre utilisateur peut probablement regarder votre écran, donc débrouillez‐vous.
    Si vous utilisez GNOME, sachez qu’il refusera de se verrouiller s’il est lancé par un autre gestionnaire de sessions que GDM. Cependant, s’il est lancé avec startx -- -seat seatX le verrouillage fonctionne, mais vous perdrez la possibilité de connecter n’importe quel utilisateur sur n’importe quel siège.

    Soyez fiers de GNU/Linux

    Les solutions pour Windows sont toutes payantes, et toutes ne permettent pas d’avoir des performances graphiques natives. Ne parlons pas de macOS/OSX, Apple serait trop triste de ne pas vous vendre une seconde machine. :)
    Je sais qu’on peut acheter des dongles USB sur lesquels on branche écran, clavier et souris, et qui affichent automatiquement sous GNU/Linux un deuxième écran de connexion ; mais ça ne permet surement pas d’avoir de l’accélération 3D si utilisée dans les navigateurs et les effets de KDE.

    Télécharger ce contenu au format Epub

    Lire les commentaires

    Sortie de Proxmox VE 5.0

    5 juillet, 2017 - 11:29

    Proxmox Server Solutions GmbH vient de publier la nouvelle version 5.0 de la plate‐forme libre de virtualisation Proxmox Virtual Environment. Parmi les principales nouvelles fonctionnalités, un gestionnaire de la réplication de stockage et un nouvel outil en ligne de commande pour importer des machines virtuelles en provenance d’autres hyperviseurs. Proxmox VE 5.0 est basée sur Debian Stretch 9.0 avec un noyau Linux 4.10.

    Réplication de stockage avec Proxmox VE

    Proxmox VE 5.0 introduit un nouveau mode de réplication de stockage, permettant de mettre à jour de façon asynchrone deux stockages locaux via le réseau, configurables depuis l’interface graphique. Cette fonctionnalité est particulièrement étudiée pour les petites structures désirant une synchronisation de leurs machines virtuelles sans avoir recours à un NAS/SAN externe.

    L’ordonnanceur de réplication est basé sur le format de calendrier de systemd, permettant de définir des intervalles de réplication très fins, au minimum d’une minute. Enfin le système de réplication permet de réduire le temps de migration d’une machine virtuelle d’un serveur à un autre, l’essentiel des données étant mises à jour en tâche de fond avant le début de la migration.

    Ceph – prêt pour la montée en charge

    Avec la version 5.0 de Proxmox VE, Ceph Rados Block Device (RBD) devient le standard de stockage distribué pour Proxmox VE. Ceph est une solution « Software‐defined », incluse dans Proxmox VE depuis 2013. En combinant Ceph et Proxmox VE, il devient possible de créer une infrastructure « hyperconvergente », où chaque nœud de la grappe de serveurs (cluster) fournit à la fois des ressources processeur pour l’hébergement de machines virtuelles, ainsi que de l’espace disque à l’ensemble de la grappe de serveurs.
    Les paquets Ceph pour Proxmox VE sont maintenant directement fournis par l’équipe de développement de Proxmox, ce qui permettra des correctifs de bogues plus rapides.

    Autres nouveautés de cette version

    Promox VE 5.0 apporte les nouveautés suivantes :

    • un outil en ligne de commande pour importer facilement des images disques provenant d’autres hyperviseurs (VMware, Hyper-V, etc.) est désormais inclus dans Proxmox VE ;
    • il est maintenant également possible de migrer des machines virtuelles même sans stockage partagé ;
    • la console virtuelle NoVNC a été mise à jour et est à présent bien mieux intégrée à l’interface graphique ;
    • enfin, il est possible de faire des actions de masse sur un groupe de conteneurs ou de machines virtuelles, et de voir directement depuis l’interface Web les périphériques affectés en mode passthrough (accès direct) aux conteneurs et machines virtuelles.
    Disponibilité

    Proxmox VE 5.0 est disponible en téléchargement. Il est possible de mettre à jour depuis les versions 4.4 et 5.0 bêta en utilisant apt-get. Proxmox VE est un produit libre distribué sous licence GNU Affero GPL v3.

    La société Proxmox Server Solution propose en outre un support Entreprise à partir de 69,90 € par processeur et par an.

    Télécharger ce contenu au format Epub

    Lire les commentaires

    Recalage d’images, PIV et corrélation d’images — Les bases théoriques

    4 juillet, 2017 - 18:18

    Le recalage d’images est utilisé dans la communauté de l’analyse d’images médicales depuis très longtemps (Barnea & Silverman, 1972, Ledbetter et al. 1979), on peut même remonter plus loin dans le temps avec les travaux de Sidney Bertram, 1963 en fournissant tous les outils via des descriptions de circuits analogiques (vraiment impressionnant pour l’époque).
    En commençant à travailler sur des images issues d’IRM, j’ai été amené à faire une bibliographie sur les outils utilisés dans l’analyse d’images médicales. J’ai constaté que leurs techniques de recalage d’images étaient très similaires à celles utilisées dans les différents domaines de la mécanique. Après beaucoup de bibliographie, je suis parvenu à situer ce qui est fait en mécanique dans les cadres proposés en analyse d’images médicales.

    Cette dépêche est l’occasion pour moi de présenter ces techniques dans le détail.

    La prochaine dépêche présentera les logiciels utilisés dans les différentes communautés scientifiques.

    Sommaire Introduction

    Dans la recherche que nous conduisons, il y a beaucoup de techniques, et la méthode qui coordonne ces techniques est tout sauf agnostique. Ce qui nous motive tous est l’extraction de la physique de nos mesures.
    Le problème qui unit l’ingénieur et le chercheur réside dans cette image du monde que nous transmettent nos mesures car elle n’est jamais exempte de biais qui peuvent jusqu’à empêcher parfois l’extraction de la moindre information physique. Les moyens permettant de diminuer les biais des observations diffèrent en général en fonction des objectifs :

    • lorsque l’on connaît précisément les phénomènes physiques en jeu, il est possible d’introduire la physique en tant que régularisation de l’identification de la transformation ; cette technique est très utilisée en mécanique des solides ;
    • lorsque l’on cherche à comprendre les mécanismes régissant les phénomènes, il est plus délicat de régulariser en se servant de la physique régissant les phénomènes, car celle‐ci n’est pas toujours connue ; de plus, la notion de matériau peut laisser place à une structure mécanique en fonction de l’échelle avec laquelle on regarde (en mécanique, la notion de structure est relative à des matériaux de type hétérogène, ou d’un ensemble de matériaux assemblés).

    Le Laboratoire de mécanique de Lille, comme beaucoup d’autres, s’intéresse particulièrement aux mécanismes, que ce soit en tribologie, turbulence de paroi ou en mécanique des matériaux, le fil rouge de ce qui est présenté ici est cette volonté de se plier aux exigences des mécanismes.

    Platon a défini dans le livre VII de La République, une distinction entre le monde du sensible et le monde des idées : le monde du sensible ne serait que la projection du monde des idées, qui nous apparaîtrait déformé par notre propre nature ; ce monde du sensible est par essence ce que nous pouvons imager, sentir.
    Je considère que le travail premier d’un scientifique qui met en œuvre de l’expérimental est de savoir analyser les images des phénomènes observés pour ensuite essayer d’accéder au monde des idées. Ce point se heurte toujours au problème de la fidélité de ce que l’on observe par rapport à l’idée qui gouverne le phénomène. Le lecteur pourra se référer à l’allégorie de la caverne afin de bien illustrer ce propos.
    Tout l’enjeu du scientifique est donc d’être capable d’avoir des images du monde sensible en connaissant les inexactitudes qui y sont attachées afin de pouvoir se faire une idée de ce qui en est la cause la plus probable.
    Le monde de l’imagerie numérique nous donne accès à l’observation de l’hétérogénéité des phénomènes et nous permet de remettre en cause ce qui n’était observable jadis que par la variation durant le temps d’une ou plusieurs quantités ponctuelles. En tant que mécanicien, je me limiterai à l’étude des conséquences de la mise en mouvement de la matière, nous verrons dans une prochaine dépêche que, malgré cette limitation, le champ d’application de l’utilisation de l’imagerie avec le miroir de la mécanique permet d’étudier une grande diversité de sujets et d’accéder à une meilleure compréhension des phénomènes en jeu.

    Nous traiterons ici de données qui ne sont pas toutes directement associables à des lois a priori, de part la complexité des systèmes observés. Les outils que nous développons s’inscrivent donc dans une logique kantisée, mais elle se heurte malheureusement à également l’opposition des conatus des scientifiques.
    Pour faire simple, les méthodes numériques généralistes présentées ici peuvent être utilisées pour appuyer les idées de scientifiques plutôt d’obédience rationaliste mais peuvent tout aussi bien être utilisées par des expérimentateurs plus portés sur l’empirisme. Cette unité de méthode n’empêche pas que les choix techniques (bien qu’appartenant tous au cadre présenté dans cet article) conduiraient à une épistémologie radicalement différente des analyses scientifiques menées par ces deux groupes sur un même objet d’étude.

    Il convient donc de mettre en place une dialectique expérimentale propre à chaque problème traité.

    Comment approcher ou établir une loi ou idée le plus justement possible ?

    Au‐delà des problèmes de biais associés à toute mesure physique, se pose la question du but même de la mesure. Il y a, d’une part, les rationalistes, qui considèrent que toute idée doit être cause ou conséquence d’un enchaînement d’idées rationnelles ; ils chercheront donc à se servir de l’expérimental pour s’approcher de leur loi au travers d’une paramétrisation ad hoc ; et, d’autre part, les empiristes, qui considèrent que toute connaissance prend source dans une expérience sensible, qui chercheront eux à construire des lois au travers de ces observations. À ce titre, je trouve intéressante la citation de Pierre Duhem : « Une loi de physique n’est, à proprement parler, ni vraie ni fausse, mais approchée. » (Traité d’énergétique, 1911), car elle nous permet de discriminer ces courants de pensée expérimentale.
    L’analyse d’image en mécanique ne fait pas exception à cette dualité : il nous arrivera de mettre beaucoup d’_a priori
    dans la mesure elle‐même, la contraignant ainsi à se plier à notre vue, mais il sera aussi utile de trouver comment ne pas mettre du tout de physique dans la mesure, pour pouvoir construire nos idées. Ainsi, je présenterai dans cet article des approches que nous avons mises au point permettant d’utiliser la mécanique pour extraire au mieux une physique inaccessible sans cette dernière, telle que la corrélation d’images numériques (Digital Image Correlation, DIC) et la Particule Image Velocimetry (PIV), mais également des méthodes innovantes permettant la réjection de solutions aberrantes, telles que la régularisation par filtre médian dans le processus de DIC.

    Recalage d’images et flot optique

    Que ce soit en analyse d’image ou en mécanique, les techniques se réclamant du flot optique (ou flux optique) sont légion. Le flot optique recouvre énormément de techniques différentes. Beaucoup d’auteurs ont déjà fait des états des lieux de ces techniques (Galvin et al., 1998_, Corpetti et al., 2006_, Baker & Matthews, 2004_), cet article ne sera donc pas une nouvelle revue des techniques déterminant le flot optique. Il n’est cependant pas possible de comprendre les idées qui ont été développées sans situer le flot optique dans ce qui se fait dans la communauté.
    Il me semble cependant plus intéressant d’aborder la présentation de ces démarches au travers du concept de recalage d’images qui est un canevas plus général que celui du flot optique.
    Il existe plusieurs méthodes utilisées pour recaler des images, certaines se basent sur l’intensité lumineuse de l’image, d’autres cherchent à détecter l’écart informations de type géométrique (c.‐à‐d. la distance), d’autres encore se situent à mi‐chemin et sont appelées « iconiques ». Une classification a été donnée par Cachier et al., 2003, elle sera utilisée.

    Principes théoriques du recalage d’images, PIV et corrélation d’images numériques

    Le recalage d’images basé sur l’intensité des niveaux de gris est une technique permettant d’apparier des images entre elles au travers d’une transformation. Cette technique est indispensable dans deux domaines : la création de vues panoramiques à partir de plusieurs prises d’images et l’analyse d’images médicales. Nous allons aborder le second point, plus complexe, car il entraîne une description plus générale. Le recalage d’images médicales a pour but de pouvoir comparer deux images de modalités différentes entre elles ou de comparer plusieurs patients entre eux.

    La DIC (Digital Image Correlation) consiste à placer une caméra devant un essai (traction, compression, flexion, multi‐axial) où l’on ajoute une texture aléatoire.
    La PIV (Particule Image Velocimetry, vélocimétrie par image de particules) consiste à rajouter des particules dans un écoulement (soufflerie, cavité entraînée…) et à les éclairer avec une nappe laser afin de les filmer.
    Ces deux techniques ont pour objectif exclusif d’identifier les transformations.

    Comme ces méthodes sont basées sur la comparaison de deux images, il convient tout d’abord de savoir comment effectuer une telle comparaison.

    Prenons par exemple le cas d’une image d’un patient prise par un IRM et par un scanner. L’IRM repose sur le contraste de résonance magnétique nucléaire alors que le scanner repose sur un contraste d’atténuation des matériaux que traversent les rayons X. Il y a donc peu de chances que les constituants du corps du patient réagissent de la même manière avec ces deux modalités différentes. Ces images ne peuvent donc pas être recalées via le flot optique, il faudra pour garder l’heuristique du recalage trouver un moyen de comparer ces images, ce qui sera introduit par la suite par la notion de métriques.
    Là encore, beaucoup a déjà été écrit à ce sujet mais un point d’entrée intéressant se trouve dans l’article de Wachinger et Navab (2010) qui illustre de manière très pédagogique pourquoi une métrique telle que celle utilisée dans le milieu de la mécanique ne peut pas fonctionner dans ce cas précis. Nous allons nous placer dans un canevas développé par Insight Tool Kit (ITK) introduit dans (Yoo et al., 2002), détaillé dans le manuel d’utilisation (Ibanez et al., 2005), et utilisé dans le logiciel de recalage ElastiX (Klein et al., 2010). Cette démarche est présentée en figure 1 :

    Figure 1 : Principe du recalage d’image ITK et Elastix

    Par convention, on appellera l’image fixe, l’image de référence, et l’image mobile, l’image que l’on souhaite recaler par rapport à cette référence. Le principe est donc le suivant :
    L’image mobile est recalée par rapport à l’image fixe au travers d’une transformation. Pour identifier au mieux cette transformation, plusieurs étapes sont nécessaires. Il faut tout d’abord définir une métrique qui permettra de comparer les deux images. Cette métrique a comme variables d’entrée un type de transformation (Transformation) (rigide, affine similitude, B‐Spline…), l’image fixe et l’image mobile. Il faut ensuite choisir une stratégie d’optimisation (Optimiseur) dans l’algorithme du gradient (Cauchy, 1847), comme la Méthode du point col, Newton, gradient conjugué… Il est également possible de ne pas évaluer la fonctionnelle (métrique) sur toute l’image mais sur un certain nombre de points (échantillonnage) aléatoire, sur une grille ou total. Enfin, il faut appliquer la transformation à l’image mobile et ce à chaque itération, ce qui nécessite un interpolateur.
    Les techniques de type Besnard et al., 2006, Réthoré et al., 2007a, reposent également sur ce schéma mais ne sont qu’un cas particulier, ce qui sera détaillé par la suite.
    Le problème à résoudre se met en équation comme présenté :

    Dans cette équation : est la métrique, la transformation paramétrée par , l’image fixe et l’image mobile.

    Rappelons que :

    où est le vecteur des transformations comme elles seront détaillées par la suite.

    Ces méthodes étant basées sur un algorithme d’optimisation de descente suivant le gradient, elles peuvent converger vers un résultat faux car le résultat est un minimum local de la fonction objectif (métrique). Pour régler ce problème, une technique de résolution pyramidale est employée, comme l’illustre la figure 2 :

    Figure 2 : Principe de l’approche pyramidale, une transformation sur une image très moyennée est trouvée, puis interpolée pour être appliquée en initialisation de l’échelle plus résolue suivante, et ce, jusqu’à la dernière échelle.

    Nous allons détailler quelques points importants du cadre utilisé ici.

    Métrique C

    Ce qui est appelé ici « métrique », ne correspond pas à la définition mathématique, car il ne satisfait pas les critères imposés pour la définition d’une distance. Il serait plus exacte de l’appeler fonction objectif, mais la communauté du recalage d’image a choisi ce terme, aussi il sera conservé ici. La littérature en compte tellement qu’il est impossible d’en faire une liste exhaustive. Celles‐ci se classent dans deux catégories distinctes, les méthodes statistiques basées sur des probabilités jointes et les méthodes directes. Dans les méthodes directes il faut être en mesure de postuler d’un lien entre les évolutions des niveaux de gris de l’image fixe et ceux de l’image mobile. Par exemple, si le flot optique est conservé entre deux images alors la métrique naturelle est l’erreur quadratique moyenne. S’il y a une relation affine entre l’évolution des niveaux de gris des deux images, alors la métrique naturelle est l’inter‐corrélation normalisée. S’il n’y a pas de relation triviale entre les évolutions de niveaux de gris, alors il faut construire une relation propre à la paire d’images étudiée au travers d’une métrique de type statistique comme l’information mutuelle. Les paragraphes suivants présentent quelques‐unes des métriques utilisées en recalage d’images médicales et applicables dans tous les domaines.

    Erreur quadratique moyenne (C=SSD)

    L’erreur quadratique moyenne (ou Sum of Squared Differences, SSD aussi appelée mean squared error) correspond à un problème au moindre carré présenté par l’équation suivante :

    où est le domaine d’intégration, le nombre de pi(vo)xels (cardinal) pour une transformation donnée.

    Inter‐corrélation normalisée (C=NCC)

    L’inter‐corrélation normalisée (ou Normalized Cross Corrélation, NCC) est une technique utilisée dans beaucoup de codes de PIV ou DIC de type blockmatching (Limb et Murphy, 1975). Elle n’est pas sensible au changement de luminosité affine et permet donc de travailler sur des images dont l’éclairement de l’image change fortement entre deux positions. C’est notamment le cas de la PIV, où la nappe laser peut ne pas être parfaitement constante, il peut y avoir de forts reflets et des particules peuvent sortir du plan du laser. C’est également le cas en imagerie médicale où les organes peuvent sortir du plan d’observation. Il est donc impossible dans de telles conditions de respecter le flot optique. Il est de plus intéressant de rappeler qu’usuellement les chercheurs utilisant ces moyens pour la turbulence règlent le temps entre les deux lasers de manière à avoir 10 pixels de déplacement moyen, ce qui peut changer fortement l’illumination des particules. La métrique d’inter‐corrélation normalisée présentée par l’équation suivante est donc théoriquement un bon moyen de résoudre ces contraintes expérimentales :

    avec

    et

    On pourrait également parler de l’information mutuelle, mais je pense que cela nuirait à la concision de l’article.

    Échantillonnage

    L’échantillonnage est défini comme le domaine (c.‐à.‐d. l’ensemble de pixels) sur lesquels la fonction objectif sera évaluée : toute l’image, un masque, une grille, ou tirée aléatoirement. Likar et Pernuš, 2001, ont démontré que le ré‐échantillonnage d’une fonction objectif, telle que l’information mutuelle, lors de l’application de la transformation pouvait conduire à un bruitage important de . Beaucoup de solutions existaient avant ce travail mais elles passaient par l’utilisation de bases d’interpolation d’ordre élevé ce qui entraînait un surcoût en temps de calcul. L’idée de Likar et Pernuš, 2001, a été de n’évaluer la fonctionnelle que sur un nombre réduit de points définis par l’utilisateur et tirés aléatoirement à chaque itération de l’algorithme de descente. Dans la pratique cette stratégie se comporte assez bien sur les deux métriques présentées précédemment mais pas avec tous les optimiseurs. Il est également souvent utilisé une sous‐intégration sur une grille ou une intégration totale. La stratégie à choisir dépend beaucoup de l’objectif que l’on se fixe : si le but est d’avoir une mesure la plus fine possible, alors la sous‐intégration pose problème ; en revanche, si l’objectif est d’obtenir une évaluation rapide des paramètres pour, par exemple, envisager une rétroaction à partir de la transformation mesurée (cas du pilotage d’un essai en déformation homogène), alors l’échantillonnage est certainement un point à ne pas négliger.

    Transformation

    Le modèle de transformation est un autre point clef de la méthode, pour une quantité donnée d’information, nous souhaitons extraire les paramètres d’une transformation. On peut énoncer plusieurs types de transformations :

    Transformations globales

    Figure 3 : Illustration de déformation globale d’une image (rotation, translations, déformations homogènes)

    Elle sont souvent linéaires, telles que le mouvement de corps rigide, la transformation affine (figure 3), la similitude, la transformation projective, qui sont souvent utilisées dans l’analyse d’images médicales. Il existe aussi des transformations globales utilisées dans la communauté de la mécanique des matériaux, telles que celles associées à la fissuration (Hamam et al., 2007, Hild et Roux, 2006) ou celles associées aux poutres (Hild et al., 2011).

    Transformations élastiques (non rigides)

    Figure 4 : Illustration des transformations élastiques d’une image (utilisation d’une base quadrangle bilinéaire)

    Il existe également une gamme de transformations appelée « élastique » dans la communauté de l’analyse d’images médicales. Elle comprend toutes les transformations qui assurent la partition de l’unité, comme les transformations basées sur les polynômes de Lagrange souvent appelées éléments finis (Besnard et al., 2006, figure 4), mais aussi les grilles de type B-Splines (Klein et al., 2010, Réthoré et al., 2010) et les méthodes étendues de type X-FEM (Réthoré et al., 2007b). Il est important de noter que ce terme « élastique » n’est pas accepté dans la communauté de la mécanique car une déformation élastique a une signification en mécanique : ainsi, il est possible d’avoir une déformation qui respecte la partition unité, mais qui n’est pas élastique (endommagement, plasticité, viscosité, etc.). Les mécaniciens du solide ne distinguent pas cette catégorie et rangent ces méthodes de transformation dans les méthodes globales (car il faut une résolution globale pour accéder à la transformation). On pourra utiliser de manière moins ambiguë la notion de « transformation non rigide ».

    Transformations locales

    Figure 5 : Illustration des transformations locales d’une image (seules les translations sont ici identifiées)

    Ces transformations, présentées en figure 5 s’appliquent à une sous‐partie de l’image et ne cherchent pas à résoudre un problème global comme les deux autres. Elles n’ont pas la nécessité de respecter la partition de l’unité. La plus connue et ancienne (Barnea et Silverman, 1972) est la recherche des translations sur chaque imagette par inter‐corrélation. Il est à noter que la méthode la plus rapide est incontestablement la technique d’inter‐corrélation, qui n’est pas un problème itératif et peut être accélérée en utilisant la FFT. Une amélioration présentée par Sutton et al., 1983, est de calculer la translation ainsi que les déformations de l’imagette. Elle est utilisée dans la plupart des logiciels commerciaux de PIV et DIC. Les transformations locales diffèrent des autres transformations de part le fait que chaque zone d’intérêt (Zone of Interest, ZOI) est traitée indépendamment. Dans la communauté de l’analyse d’images, ce problème a été résolu très tôt par Lucas et Kanade, en 1981, qui détermine le flot optique sur des ZOI. Cette méthode est de loin la plus intéressante car elle permet d’utiliser les transformations définies précédemment, mais à l’échelle locale. C’est de plus la seule méthode de blockmatching qui trouve sa place dans le canevas présenté.

    Interpolateur

    L’interpolateur sert à évaluer la valeur de et lors de l’évaluation de la métrique. En effet, les déplacements sont recherchés à une précision inférieure au pixel, il faut donc aller interpoler les valeurs au voisinage de la position définie. Beaucoup d’interpolateurs sont utilisés dans la littérature mais les B‐splines prédominent fortement. Une excellente revue de l’impact d’un interpolateur sur l’image est faite par Getreuer, 2011.

    Figure 6 : Impact des étapes successives d’interpolation d’une rotation en fonction de l’interpolateur choisi (Getreuer, 2011).

    La figure 6 illustre le fait que si l’on cumule des successions de transformations (ici une rotation), alors le choix de l’interpolateur devient fondamental. Sur cette figure, seule une B‐spline d’ordre 11 parvient à ne pas modifier fortement la structure de l’image. Cela montre aussi qu’il est fondamental de ne pas cumuler les interpolations, aussi la stratégie utilisée ici est de toujours travailler avec (la transformation totale est appliquée à l’image mobile initiale) et non avec des successions d’images interpolées de manière cumulative (comme présenté figure 6).

    Optimiseur Dérivation de C

    Il convient de rappeler que les méthodes d’optimisation utilisées ici sont toutes des méthodes basées sur le calcul du gradient de . Le procédé est détaillé sur un exemple en calculant le gradient de l’erreur quadratique moyenne définie précédemment en utilisant la composition des dérivées.

    Pour chaque métrique utilisée il faut calculer le gradient de la fonctionnelle.

    Algorithme du gradient Formalisation mathématique

    Une fois le calcul du gradient de la fonction objectif effectué, il faut trouver une stratégie pour converger vers son minimum.

    Le principe de la minimisation de la fonctionnelle est défini par l’équation suivante :

    La taille du pas de l’algorithme de gradient est pilotée par la valeur de qui peut être constante ou remise à jour à chaque itération suivant différentes méthodes.

    Soit :

    Un point fondamental dans une descente suivant le gradient est de déterminer quelle direction de recherche utiliser. Ce choix se fait au travers de ou itérativement par choix des (gradient conjugué et stochastique), nous présenterons ici les principales méthodes utilisées en optimisation.

    • descente suivant le gradient :
    • Newton avec la matrice hessienne, telle que  :
    • Gauß‐Newton :
    • Levenberg‐Marquardt :
    • quasi‐Newton (BFGS) :
    • gradient conjugué :
    • gradient stochastique :

    Pour les transformations de type élastique, ces relations sont vraies mais doivent être appliquées au niveau de l’élément (FEM, X-FEM) ou à l’échelle du patch (B‐splines).

    Discussion des méthodes d’optimisation

    Il est possible de construire l’opérateur :

    en se servant de la moyenne des gradients de l’image fixe et mobile ce qui permet d’accélérer la procédure d’optimisation. Lorsque cette moyenne est appliquée à la méthode de Gauß‐Newton la méthode s’appelle ESM pour Efficient Second order Minimization, elle a été inventée par Benhimane et Malis, 2004, qui prouvèrent qu’elle avait une excellente convergence pour la , et validée sur d’autres métriques par Wachinger et Navab, 2009. Cette méthode a également été utilisée dans notre communauté par Réthoré et al., 2007a. Il est important de noter que certains auteurs choisissent de ne pas mettre à jour ce terme en le calculant à partir de l’image fixe, dans ce cas on identifie la transformation opposée. Cette technique a l’avantage de ne calculer qu’une seule fois la dérivée de l’image et la matrice Hessienne (pour ), ce qui permet un gain de calcul important dans le cas de la méthode de (quasi ou Gauß) Newton. Ceci peut être très avantageux pour le gradient conjugué, s’il stocke les vecteurs construits au fur et à mesure jusqu’à ce que la base approchée soit stationnaire. Cette base pourrait être utilisée sur l’image suivante d’une séquence comme initialisation, ce qui crée un gain de temps notable et, à partir d’un certain nombre d’itérations, il ne rajoute plus de vecteurs à la base à chaque nouvelle itération du processus d’optimisation. Le principal problème des méthodes de type Newton ou quasi‐Newton est la sensibilité au choix des paramètres initiaux. Si les paramètres sont éloignés, alors il est probable que l’algorithme converge vers un minimum local. S’il est vrai que la technique pyramidale présentée ici permet d’estimer des paramètres à des échelles plus grossières évitant ainsi le piège local, il arrive que cette approche ne suffise pas. D’un autre côté, les méthodes de descente suivant le gradient permettent un écart plus grand par rapport aux paramètres initiaux mais convergent plus lentement. La méthode de Marquardt, 1963, permet de profiter des avantages des deux méthodes mais le choix du et son évolution au cours du temps peut entraîner une convergence faible au niveau de l’optimum.

    Une des méthodes les plus performantes pour résoudre ce système est la méthode quasi‐Newton de type Broyden‐Fletcher‐Goldfarb‐Shanno où les vecteurs et sont des vecteurs de rang 1 de base différente. Les détails de la création des vecteurs et sont disponibles sur Wikipédia. Un point important est qu’il est possible de déterminer explicitement l’inverse de l’approximation de la Hessienne (Sherman et Morrison, 1950). De ce fait, cette méthode peut également être utilisée efficacement conjointement avec l’ESM.
    Une attention toute particulière doit être apportée à la méthode de type gradient stochastique. Cette technique d’optimisation a été développée pour résoudre des problèmes de grande taille dans le domaine de l’apprentissage automatique. Lorsque les systèmes deviennent très gros, il est délicat de calculer l’inverse de la hessienne du problème, voire parfois impossible. Il reste alors comme possibilité de l’approximer (Gauß‐Newton, quasi‐Newton). Le coût numérique étant alors assez élevé, il est alors possible de faire une simple descente suivant le gradient, mais les propriétés de convergence sont alors beaucoup moins bonnes qu’avec une méthode de Newton, car la direction de recherche n’étant pas bonne, il faut beaucoup plus d’itérations. L’idée du gradient stochastique est de ne pas évaluer la fonctionnelle sur toutes les données mais seulement sur un échantillonnage tiré aléatoirement. Bottou et Bousquet, en 2008, ont montré que dans ce cas, l’utilisation de la Hessienne n’améliorait pas la vitesse de convergence et que cette méthode converge plus vite (en termes de temps et non d’itérations) pour les problèmes de grande taille que les méthodes qui approximent la matrice Hessienne. Cette méthode permet donc de s’affranchir du calcul de la matrice hessienne, assure une convergence vers un minimum global dans le cas d’une fonctionnelle convexe et vers un minimum local pour une fonctionnelle non convexe. Klein et al., en 2005, présente une accélération d’un facteur 500 par rapport à un échantillonnage complet. Il a de plus été montré dans la sous‐section échantillonnage que le sous‐échantillonnage permet de lisser la fonction objectif. Nous rappelons que l’obtention d’une fonctionnelle convexe est assurée par le processus pyramidal.

    Stratégie de régularisation

    La stratégie la plus utilisée en ce qui concerne la régularisation est celle mise en œuvre par Tikhonov et Glasko, en 1965, et présentée dans l’équation suivante ; elle consiste à favoriser les solutions dont les normes des inconnues sont petites :

    Dans notre cas :
    en fonction de la stratégie d’optimisation choisie et est égal à la dérivée de la dérivée de . La matrice peut quand à elle être l’identité ou n’importe quel opérateur linéaire tel que, par exemple, la matrice de raideur d’un système à élément finis ou alors une matrice représentant un filtre passe‐bas peut être utilisée pour éliminer les variations rapides qui sont non différentiables du bruit de mesure.

    Après de longues réflexions, nous avons décidé de ne pas implémenter ce canevas pour la régularisation dans nos outils. Bien qu’apparemment séduisantes, les régularisations de Tikonov ne permettent que d’utiliser des normes , car les méthodes d’optimisations implémentées nécessitent une fonctionnelle convexe. Cela entraîne, par exemple, que les régularisations de type (qui conservent les discontinuités) ne nous sont pas accessibles. Il est possible de formuler le problème différemment, Cachier et al, 2003 ont montré qu’il est possible de formuler le problème de recalage d’image iconique de type démon en tant que problème de flot optique au travers d’une minimisation alternée.
    Ainsi, ils formulent le problème de recalage de la manière suivante :

    Les termes et sont les transformations, c’est‐à‐dire des translations pixel à pixel, il n’y a donc pas de base de transformation ici, la cohérence spatiale étant assurée par les énergies de pénalisation pondérées par les coefficients et  ; représente une énergie de pénalisation telle que le laplacien du déplacement en mécanique des fluides ou en mécanique du solide.

    La méthode itérative de résolution est la suivante :

    • d’abord résoudre l’équation suivante en utilisant un algorithme de descente au gradient en version ESM :
    • puis, résoudre l’équation suivante :

    Cette équation pourrait se résoudre également via un algorithme de descente au gradient, mais il existe un moyen de la résoudre par convolution comme démontré en annexe de Cachier et al., 2003_.

    Nous nous sommes inspirés de cette idée, mis à part le fait que nous ayons généralisé cette méthode de régularisation à n’importe quelle méthode de filtrage et non plus à une simple convolution. Après différents tests, nous avons constaté que le filtre médian était l’outil de régularisation le plus efficace dans la plupart des cas.

    La prochaine dépêche présentera les logiciels utilisés dans les différentes communautés scientifiques.

    Télécharger ce contenu au format Epub

    Lire les commentaires

    Revue de presse de l’April pour la semaine 26 de l’année 2017

    4 juillet, 2017 - 17:35

    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

    Dernière revue de presse avant la pause estivale. À bientôt en septembre !

    [Next INpact] Vie privée et sécurité de nos données : comment mieux soutenir, informer et protéger ?
    Par David Legrand, le jeudi 29 juin 2017. Extrait :

    « De nombreux outils qui assurent le fonctionnement du Web et la sécurité de nos échanges, ou même la protection de notre vie privée, dépendent d’un mode de financement assez particulier : le don. Mais voilà, les efforts en la matière sont assez éclatés, ce qui mène parfois à une efficacité limitée. Et si l’on pensait les choses autrement ? »

    [LaTeleLibre.fr] La Guerre des Civic Tech
    Par la rédaction, le mardi 27 juin 2017. Extrait :

    « S’impliquer, voter, cliquer. Voilà la recette de la démocratie version 2.0. Simon est parti à la rencontre des Civic-tech, ces acteurs qui permettent à cette démocratie d’éclore. Mais, entre start-up, associations, partisans du logiciel libre et défenseurs du Fermé, le monde des Civic Tech ne rime pas forcément avec participation citoyenne. »

    [ZDNet France] Microsoft / Éducation Nationale : la CNIL émet des réserves
    Par Louis Adam, le mardi 27 juin 2017. Extrait :

    « Dans une lettre obtenue et publiée aujourd’hui par NextInpact, la CNIL revient sur le projet de charte en cours de préparation entre l’Éducation nationale et Microsoft. La Commission y pointe plusieurs manques en matière de protection des données personnelles. »

    [Numerama] L’inventeur du Web livre un plaidoyer en faveur de la neutralité du Net
    Par Julien Lausson, le lundi 26 juin 2017. Extrait :

    « Tim Berners‐Lee, le principal inventeur du Web, signe une tribune pour appeler à la défense de la neutralité du Net, dont le principe est gravement remis en cause aux États‐Unis. »

    Télécharger ce contenu au format Epub

    Lire les commentaires

    OpenConcerto 1.5

    4 juillet, 2017 - 13:00

    La version 1.5 du logiciel OpenConcerto vient de sortir. OpenConcerto est un logiciel complet de gestion d’entreprise incluant : gestion commerciale, comptabilité (dont l’analytique) et paye. Il dispose aussi d’une interface de caisse pour les points de vente et d’un système de préparation de commandes (picking).
    Modulaire, le logiciel propose des greffons pour la DSN, la gestion de prospects, planning, SAV, GED…

    OpenConcerto est disponible pour GNU/Linux, macOS et Windows. Une version Cloud est proposée pour une solution clef en main.

    Le logiciel, sous licence GPL, est téléchargeable dès maintenant en version 1.5 sur toutes les plates‐formes prises en charge en versions monoposte et multiposte. La version 1.5 est l’occasion d’inaugurer la gestion de documents intégrée, ainsi qu’une refonte de l’interface de caisse.

    À la différence des solutions habituelles du secteur que l’on peut trouver dans les logiciels libres, OpenConcerto n’est pas une application Web, mais une application riche. Avec l’ajout de modules spécifiques, OpenConcerto constitue un PGI (ERP) véloce et adaptable. Il est actuellement utilisé en production dans des sociétés avec plus de 150 utilisateurs simultanés.

    Cette application écrite en Java repose sur des bases de données libres, dont PostgreSQL et H2.

    OpenConcerto est un progiciel de gestion intégré (PGI, ERP en anglais pour Enterprise Resource Planning) proche en architecture de Microsoft Dynamics Nav. Au niveau des fonctionnalités, vous trouverez les grands classiques des produits « en boîte », mais également les éléments d’un PGI complet, comme la gestion multi‐société, multi‐poste, multi‐utilisateur ou encore la traçabilité.

    Devis, factures, avoirs, commandes, règlements et bons de livraison, tout y est. Le logiciel permet de gérer facilement clients, fournisseurs, achats, ventes, articles et stocks. La gestion commerciale est directement liée à la comptabilité (norme française), ce qui évite les doubles saisies.

    L’accent est porté pour l’instant sur le retour utilisateur, afin de pouvoir fournir une base la plus complète possible. Le logiciel s’adresse à un public large :
    * l’auto‐entrepreneur, qui y trouvera de quoi réaliser devis, factures, paye et comptabilité ;
    * la petite entreprise, qui y verra une solution multiposte complète ;
    * la moyenne entreprise qui, économisant un coût de licence, pourra investir dans la création de modules spécifiques à son activité.

    En plus de la résolution attendue des bogues de la version 1.4, et d’un grand nombre d’améliorations de l’interface, OpenConcerto 1.5 apporte principalement :

    • une refonte de l’interface de caisse ;
    • le prise en charge des nouveaux afficheurs LCD et douchettes ;
    • la gestion de taxes spécifiques (Codifab, par exemple) ;
    • la saisie par douchette (BL) ;
    • la gestion électronique de documents ;
    • de nouveaux modules : SAV, impression d’étiquettes.

    Il est à noter que sont proposés pour une utilisation professionnelle : formation, manuel et contrat de maintenance.

    Télécharger ce contenu au format Epub

    Lire les commentaires

    L’heure du test — fork 2 — Qubes OS

    4 juillet, 2017 - 11:36

    L’heure du test est un rendez‐vous pour les tests et guides d’installation de distributions, en exposant leurs avantages et inconvénients. Ce fork présente Qubes OS, un système d’exploitation libre qui prétend ne pas être une distribution !

    Qubes OS est un système d’exploitation focalisé sur la sécurité. Il se situe à mi‐chemin entre une distribution classique et un hyperviseur. Il s’appuie sur l’hyperviseur Xen et propose un système sécurisé basé sur l’isolation.

    Sommaire Prérequis matériels

    D’un point de vue matériel, Qubes OS est compatible avec la plupart des composants. Cependant, si vous avez du matériel très récent ou très ancien, l’installation peut être compliquée ou impossible. En cas de doute, consultez la table de compatibilité matérielle et / ou le fil de discussion des utilisateurs.

    Pour résumer, votre processeur doit être du type x86-64 et devrait avoir des fonctionnalités dédiées à la virtualisation (Intel VT-x / AMD-v). Vous devez également disposer d’au moins 4 Gio de mémoire vive (8 Gio devraient être largement suffisants pour la plupart des utilisateurs) et 32 Gio d’espace disque. Il est recommandé d’utiliser un SSD et une puce graphique Intel intégrée.

    Installation

    Avant d’installer Qubes OS, vérifiez les paramètres de votre BIOS. Les réglages exacts vont dépendre de votre matériel. Le conseil général est d’activer toutes les options liées à la virtualisation et de désactiver toutes les options liées à l’UEFI. En cas de problèmes, consultez le fil de discussion des utilisateurs.

    L’installation est relativement classique, et on trouve sur YouTube de très bons tutoriels. Par exemple, pour l’installation de Qubes OS 3.2, il y a ce tutoriel en anglais. Il y a également un tutoriel en français pour l’installation de Qubes OS 3.1.

    Configuration

    Lors de l’installation, on peut choisir d’installer la configuration par défaut. Elle est très utile pour prendre en main Qubes OS. Et comme toute configuration générique, vous vous rendrez vite compte qu’elle convient mal à vos usages. On présente ici certaines spécificités de Qubes, ainsi qu’une configuration typique, et une configuration plus avancée.

    Dom0

    C’est le chef d’orchestre. Dans la version 3.2, il est basé sur Fedora et contrôle l’hyperviseur, l’interface graphique et les périphériques d’entrée (clavier, souris…). Pour des raisons de sécurité, il a un accès au réseau qui est filtré et limité aux mises à jour.

    Les modèles

    Les modèles (templates), correspondent à des distributions GNU/Linux. On y accède uniquement en ligne de commande pour gérer les paquets installés. L’équipe de développement de Qubes OS propose trois modèles :

    • Fedora, le modèle par défaut, on est actuellement sur la version 24 ;
    • Fedora-minimal, une version minimaliste du modèle par défaut ;
    • Debian, on est actuellement sur la version 8 (Jessie).

    La communauté propose également des modèles pour Whonix, Ubuntu et Archlinux.

    Les machines virtuelles (VM) basées sur un modèle

    De nombreuses machines virtuelles peuvent être basées sur un même modèle. Pour chaque machine virtuelle, on spécifie un maximum de mémoire vive et d’espace disque accessible. Une machine virtuelle basée sur un modèle dispose de quelques répertoires en propre :

    • /home ;
    • /usr/local ;
    • /rw/config.

    Toute modification des fichiers présents dans les autres répertoires est faite avec une copie à la volée (copy on write) et n’est pas pérenne, elle sera détruite lorsque la machine virtuelle va être éteinte ou redémarrée.

    Les machines virtuelles « classiques »

    On peut également créer des machines virtuelles « classiques » qui ne sont pas basées sur un modèle. On leur associe un maximum de mémoire vive et d’espace disque accessible, et l’on peut y installer une distribution GNU/Linux ou BSD classique, ou bien Windows.

    Les machines virtuelles « jetables »

    Elles s’appuient sur le modèle par défaut défini par l’utilisateur, se lancent en quelques secondes et ne disposent d’aucun stockage pérenne. Elles permettent d’ouvrir des fichiers douteux sans compromettre la machine virtuelle d’origine.

    Par exemple, depuis Thunderbird, un clic droit sur une pièce jointe de type PDF propose d’ouvrir le document dans une machine virtuelle jetable. On peut également utiliser un navigateur Internet dans une machine virtuelle « jetable » pour explorer un site qui n’est pas de confiance.

    Configuration typique

    Dans une configuration typique, on va avoir trois modèles et une série de machines virtuelles :

    • Un modèle A, Fedora minimaliste complété par des pilotes réseau :
      • une machine virtuelle, on lui attribue en exclusivité la ligne PCI reliée à la carte réseau ;
    • un modèle B, Fedora minimaliste :
      • une machine virtuelle, elle fera office de pare‐feu entre la machine virtuelle « Internet » et les autres machines virtuelles ;
    • un modèle C, Fedora classique avec tous les logiciels utilisés régulièrement :
      • une machine virtuelle « secret », jamais connectée au réseau, pour stocker des données confidentielles,
      • une palanquée de machines virtuelles connectées au réseau à travers le pare‐feu ; idéalement, chaque machine virtuelle va correspondre à un usage spécifique : « travail », « banque », « réseaux sociaux », etc.,
      • une machine virtuelle dédiée aux visio‐conférences, on lui attribue un accès exclusif au micro et à la webcam.
    Configuration atypique

    De nombreux ordinateurs portables ont deux cartes réseau, une filaire et une sans‐fil. On aura alors deux machines virtuelles réseau, chacune avec un accès exclusif à l’une des cartes, et un pare‐feu dédié. On pourra également créer un pare‐feu qui fera office de réseau privé virtuel (VPN). Chaque machine virtuelle pourra alors utiliser :

    • le pare‐feu relié à la connexion réseau filaire ;
    • le pare‐feu relié à la connexion réseau sans‐fil ;
    • le pare‐feu du réseau privé virtuel, relié à l’une des connexions réseau.

    On pourra dédier une machine virtuelle à la gestion des périphériques USB, ces derniers étant une valeur sure en termes d’infections. On pourra également dédier une machine virtuelle à la gestion du chiffrement GPG, de sorte que les clefs privées ne sortent pas de cette machine virtuelle.

    Avantages et inconvénients

    L’avantage principal de Qubes OS, c’est le niveau de sécurité plus élevé qu’il procure. On peut très simplement attribuer à une machine virtuelle un accès exclusif à un périphérique. De plus, si une machine virtuelle a une activité suspecte, on peut la détruire et en générer une nouvelle en quelques clics. Et ce, sans interférer avec les autres machines virtuelles.

    Le pendant de cette sécurité plus élevée, c’est une utilisation plus complexe. L’installation d’un logiciel supplémentaire dans un modèle se fait en ligne de commande, ce qui rebutera plus d’un néophyte. De plus, il faut une certaine discipline ou hygiène dans l’utilisation quotidienne. Ainsi, lorsque l’on est sur le navigateur de la machine virtuelle « banque », il faut éviter d’ouvrir compulsivement un onglet pour aller sur YouTube ou Facebook…

    Globalement, Qubes OS n’est pas accessible au grand public. Néanmoins, après un bref apprentissage, toute personne ayant déjà vu un terminal s’y retrouve. L’ergonomie est relativement bonne. On peut copier‐coller des éléments sélectionnés entre machines virtuelles simplement (Ctrl + C puis Ctrl + Maj + C, suivi de Ctrl + Maj + V puis Ctrl + V). Et depuis le navigateur de fichiers, un clic droit sur un dossier ou un fichier permet de le copier ou de le déplacer vers une autre machine virtuelle.

    Un inconvénient majeur de Qubes OS est la gestion du ou des processeurs graphiques. Lorsqu’il n’y a qu’un processeur graphique sur la machine, Dom0 en a une utilisation exclusive. Les machines virtuelles disposent alors d’une accélération graphique limitée, ce qui est pénalisant pour jouer ou regarder des vidéos en haute définition. Il serait possible d’utiliser simultanément plusieurs processeurs graphiques, mais c’est complexe et risqué.

    Un avantage majeur de Qubes OS est la machine virtuelle « jetable ». Elle est intégrée dans Thunderbird et dans le gestionnaire de fichiers et se lance en quelques secondes, ce qui permet d’ouvrir sereinement des liens et des fichiers douteux.

    On notera que Qubes OS intègre nativement Whonix et se trouve donc dans la lignée de TAILS ou Subgraph OS : c’est un outil qui permet de renforcer la sécurité et la confidentialité des données et de leurs échanges. Ce qui est probablement inestimable pour certains utilisateurs.

    Remarques

    La version 4.0 de Qubes devrait arriver prochainement. Les spécifications matérielles vont changer et il faudra utiliser du matériel implémentant la virtualisation de second niveau (SLAT).

    La majorité des membres de l’équipe de développement sont liés à Invisible Things Lab. C’est l’entreprise qui a financé le projet lors de son lancement.

    Télécharger ce contenu au format Epub

    Lire les commentaires

    GDPR : les actions indispensables de conformité (étude longue)

    3 juillet, 2017 - 09:48

    Le site Données personnelles publie une étude assez complète sur le règlement européen en matière de protection des données personnelles qui entrera en vigueur en mai 2018 (le GDPR / RGPD) et qui va révolutionner la protection de la vie privée. Les nouvelles sanctions, en particulier, vont inciter les organisations (les entreprises et l’État) à appliquer cette règlementation. Le règlement est long (100 pages — 99 articles de loi…), mais voici en substance onze actions pratiques qui peuvent être mises en œuvre pour se préparer au règlement :

    1. minimiser les données personnelles collectées ;
    2. s’assurer du fondement juridique du traitement ;
    3. éviter de traiter des données sensibles ;
    4. afficher les mentions légales ;
    5. respecter le droit à la portabilité des données ;
    6. mettre en place un registre de conformité ;
    7. assurer la sécurité des données personnelles ;
    8. créer un registre de violations de données personnelles ;
    9. nommer un délégué à la protection des données ou data privacy officer (DPO) ;
    10. mettre en place une évaluation d’impact sur la vie privée ou privacy impact assessment (PIA) pour les traitements les plus sensibles ;
    11. s’assurer de ne pas transférer des données personnelles hors union européenne.

    À méditer !

    Télécharger ce contenu au format Epub

    Lire les commentaires

    Agenda du Libre pour la semaine 27 de l’année 2017

    2 juillet, 2017 - 11:33

    Calendrier Web, regroupant des événements liés au Libre (logiciel, salon, atelier, install party, conférence), annoncés par leurs organisateurs. Voici un récapitulatif de la semaine à venir. Le détail de chacun de ces 27 événements (0 en Belgique, 23 en France, 3 au Québec et 1 en Suisse) est en seconde partie de dépêche.

    Sommaire [FR Saint-Étienne] Rencontres Mondiales du Logiciel Libre - Du samedi 1 juillet 2017 à 09h00 au vendredi 7 juillet 2017 à 23h00.

    Les Rencontres Mondiales du Logiciel Libre (RMLL) sont un cycle de conférences, d’ateliers et de tables rondes autour du Libre et de ses usages.

    Cet événement se déroule chaque année dans une ville différente depuis l’année 2000.

    Rassemblant plusieurs milliers de personnes et pour la première fois à Saint-Étienne, en Auvergne- Rhône-Alpes, la 17ème édition des Rencontres Mondiales du Logiciel Libre se déroulera du 1er au7juillet 2017.

    Événement d’ampleur internationale , des conférenciers viennent de l’autre bout du monde présenter leurs projets et discuter de leurs évolutions avec un public attentif et nombreux.

     Au delà du logiciel, d’autres domaines seront aussi représentés comme les matériels libres (Hackerspace, Fablab,…) et la création artistique sous Licences libres (graphisme, musique, cinéma…).

    Plus d'infos : rmll.info

    [FR Grasse] SophiaConf 2017 - Du lundi 3 juillet 2017 à 18h00 au jeudi 6 juillet 2017 à 20h00.

    Web & API, Internet of Things, Intelligence Artificielle et Technologies Open Source

    Depuis 8 ans, la commission Open Source de Telecom Valley vous propose LE rendez-vous annuel des professionnels et passionnés azuréens de technologies Open Source.

    SophiaConf 2017, c'est

    • 3 soirées de conférence gratuites
    • 1 journée de workshops techniques sur Docker, Deep Learning, Blockchain, Devops, Design Thinking, Nginx et HAProxy
    • 24 experts
    • Le meilleur de l’Open Source sur la Côte d’Azur, concentré sur 4 jours, avant les vacances d’été
    • Du*partage, des échanges, de la convivialité* autour de 3 thématiques : Frameworks web & API  ·  Internet of Things  ·  Intelligence Artificielle

    Programme complet et inscription www.sophiaconf.fr

    [FR Grenoble] Atelier OpenStreetMap – Initiation et partage d’expérience - Le lundi 3 juillet 2017 de 18h30 à 21h00.

    Le collectif « OpenStreetMap Grenoble » vous propose de vous initier à Open Street Map le 3 juillet ! Cette soirée sera dédiée à l’accueil des nouveaux contributeurs, ainsi qu’au partage d’expérience et à la préparation de l’année prochaine pour les anciens contributeurs.
    Que vous soyez débutant ou confirmé, cette soirée est ouverte à tous !

    Programme :

    • 18h30 – 20h00 : Apéro, initiations, partage d’expérience
    • 20h00 – 21h00 : Debriefing de l’année et préparation de l’année prochaine (agenda…), fonctionnement du groupe local

    C’est quoi OSM ? OpenStreetMap (OSM) est un projet international fondé en 2004 dans le but de créer une carte libre du monde. Nous collectons des données dans le monde entier sur les routes, voies ferrées, les rivières, les forêts, les bâtiments et bien plus encore ! Les données cartographiques collectées sont ré-utilisables sous licence libre ODbL (depuis le 12 septembre 2012).

    Pour plus d’information :  inscrivez-vous à la liste locale OSM de Grenoble

    [QC Québec] Linux-meetup Québec - Le mardi 4 juillet 2017 de 18h00 à 21h00.

    Bonjour à tous!
    Vous êtes invités à participer au prochain Linux-Meetup de Québec qui aura lieu le mardi 4 juillet 2017 au Korrigane Brasserie artisanale de 18h à 21h. Vous pouvez souper sur place avec nous et les discussions de groupe commenceront vers 19h.
    Coordonnées :

    [QC Montréal] Linux-Meetup Montréal - Le mardi 4 juillet 2017 de 19h00 à 22h00.

    Local de la rencontre : à venir
    Programmation de la rencontre
    Ce mois-ci, nous aurons comme conférenciers invités deux passionnés de logiciel libre:

    [FR Saint-Étienne] Les Rencontres Professionelles du Logiciel Libre (RPLL) 2017 - Du mardi 4 juillet 2017 à 09h20 au mercredi 5 juillet 2017 à 18h00.

    Les 4 et 5 juillet 2017 auront lieu les Rencontres Professionnelles du Logiciel Libre (RPLL) à Saint-Etienne (42).

    C’est un salon organisé par PLOSS-RA à destination des entreprises, des collectivités territoriales, administrations et associations. Une vingtaine d’ENL seront présentes pour échanger et présenter leurs services, produits autour du Logiciel Libre et de l’Open Source.

    Ce sera aussi l’occasion, par le biais de conférences et d’ateliers, de découvrir ces solutions et d’avoir des retours d’expériences.

    Cette événement se fait en parallèle des Rencontres Mondiales du Logiciel Libre (#RMLL2017 : plus d’information https://2017.rmll.info/fr/ ).

    Vous pouvez retrouvez tous les détails des RPLL sur le site dédié : https://www.rpll.fr/ (pour devenir exposant, nous sponsoriser ou tout simplement visiter) et sur les réseaux sociaux. (Twitter et Mastodon).

    Vous pouvez dès à présent retrouver tous les communiqués de presse ainsi que le prix des stands sur le site.

    [FR Paris] Les premiers mardi de la monnaie libre et équitable - Le mardi 4 juillet 2017 de 19h00 à 21h00.

    Afin de faire vivre notre première monnaie libre, Gwan, mise en orbite depuis le 8 mars dernier, nous vous proposons des rencontres mensuelles tous les premiers mardis du mois à PARIS pour

    1. échanger nos clés publiques G1et/ou Gtest, en vue d'accorder nos certifications en toute sécurité
    2. échanger sur nos expériences, idées ou autres propositions sur l'usage de G1
    3. aborder le domaine de la technique noeuds Duniter, Césium, Sakia, Silkaj, Yunohost, etc.

    Les 2 premières rencontres ont eu lieu les 4 avril et 2 mai derniers à partir de 18 Heures 30 au café Bert's situé au forum des Halles sous le cinéma, à quelques mètres de la Place carré.

    La prochaine rencontre aura lieu le 6 juin prochain, même lieu à partir de 19 heures.

    Afin de gérer au mieux les rencontres, 2 mailings listes sont créées,

    l'une pour les inscriptions aux rencontres

    S'abonnerhttps://framalistes.org/sympa/subscribe/inscriptions_reunions_gtest_g1
    Se désabonnerhttps://framalistes.org/sympa/sigrequest/inscriptions_reunions_gtest_g1

    et l'autre, pour les échanges et discussions

    S'abonnerhttps://framalistes.org/sympa/subscribe/monnaies.gtest.g1
    Se désabonnerhttps://framalistes.org/sympa/sigrequest/monnaies.gtest.g1

    Précision ces rencontres sont LIBRES et donc largement ouvertes à tous quelque soit la géolocalisation de chacun

    A bientôt.

    site officiel : https://fr.duniter.org/

    forum : https://forum.duniter.org/

    [FR Lyon] Mapathon Missing Maps Validation - Le mardi 4 juillet 2017 de 19h15 à 22h00.

    Venez nous aider à cartographier sur OpenStreetMap, la carte du monde collaborative et libre au cours d'un mapathon !

    CartONG et l'Atelier des médias, vous invitent à un mapathon Missing Maps spécial VALIDATION

    Vous êtes évidemment bienvenu si vous souhaitez tout simplement découvrir OSM et la contribution..

    L’objectif du projet Missing Maps est de créer des cartes pour les zones de crise des pays en voie de développement qui en ont le plus besoin.

    En effet, on peut penser qu'aujourd'hui toutes les parties du monde sont cartographiées, mais en réalité nombreuses régions ne possèdent encore aucunes cartes.

    L'objectif de Missing Maps est donc de cartographier toutes ces zones encore invisibles sur les cartes, pour permettre par la suite aux collectivités locales et acteurs de l'humanitaire de pouvoir agir plus efficacement en cas de crise. 

    MAPATHON SPECIAL VALIDATION

    A l'occasion de ce prochain mapathon à Lyon nous proposons de vous former à la validation ! Vous avez déjà participé à un mapathon et appris à contribuer ?

    Maintenant apprenez à valider ! La validation est l'étape de correction et de vérification qui permet de s'assurer que la carte a bien été faite en suivant les instructions du projet, et sans erreurs.

    Le principe est simple, on retourne sur les carrés marqués comme complétés, et on corrige/ajuste les contributions avant de marquer le carré comme validé !

    Cette étape est indispensable pour finir un projet Missing Maps.

    Lors de ce mapathon spécial apprentissage à la validation, nous vous présenterons les erreurs courantes à corriger, et nous vous aiderons à résoudre les conflits qui apparaissent dans la base de données.

    Pensez à installer JOSM avant de venir au mapathon !

    Le programme de la soirée
    • 19h15 : accueil des participants
    • 19h20 : Mot de bienvenue, présentation du projet Missing Maps et du déroulement de la soirée
    • 19h30 : Formation à la validation
    • 19h40 : Cartographions !

    Lightning Talks 

    • 22:00 Fin du mapathon
    OU

    L' Atelier des Médias nous accueille gracieusement pour cet événement, nous les en remercions !

    Venez nombreux, et n'oubliez pas votre ordinateur portable, et souri(re)s !

    [FR Montpellier] Install Par Tous ! Install Party ! - Le mercredi 5 juillet 2017 de 12h00 à 17h00. Reprenez le contrôle de vos machines. Avec un Gnou et un Manchot

    Communément appelées "Install Party" ces événements sont dédiés à l'installation, mais aussi et surtout au support, de systèmes GNU/Linux sur vos ordinateurs personnels (ou pro d'ailleurs), dans le but de se passer des méchants systèmes d'exploitation qui rament, espionnent, et vous ont été imposés.

    Bref reprendre le contrôle de vos machines pour de vrai !

    Déroulement typique de l’installation sur un ordi :

    • Discuter ! Savoir quel sont vos attentes pour ce nouveau système : faut-il des outils spécifiques, aurez-vous tout ce qu'il vous faut pour profiter de votre appareil, supportera-t-il telle ou telle techno, etc.
    • Déterminer la bonne distribution en fonction de l'appareil (capacité, mémoire, cpu, etc), mais aussi en fonction de vos attentes.
    • Essayer ! La plupart des distributions linux peuvent tourner sur votre appareil sans les installer (Live) en utilisant uniquement la mémoire vive, sans toucher au disque dur. Cela permet de vérifier qu'elle marche correctement, et qu'elle réponds aux attentes.
    • Backup ! Il est fortement recommandé de faire des sauvegardes de toutes vos données AVANT DE VENIR. Cette étape peut-être longue, fastidieuse, et surtout ne concerne personne d'autre que vous (aucune raison d'avoir vos données qui se baladent sur des disques ou clef USB dans le hackerspace). Mais le cas échéant nous nous doterons d'un moyen de sauvegarde, ou vous amenez le votre, et on sauve tout ce qui peux être sauvé.
    • INSTALL !!! Cette fois-ci c'est parti on installe le système sur le disque dur, en éliminant le précédent (recommandé ;) ), ou en le conservant sur le coté au cas où (but why ?).
    • On finalise enfin l'installation par l'ajout des logiciels dont vous avez besoin, et on en profite pour vous montrer comment le faire vous même, comment se gèrent les mises à jour, et toutes les astuces propre à GNU/linux pour que vous soyez à l'aise dans votre nouvel environnement.

    Une fois rentré à la maison avec votre ordinateur tout propre, il se peut que vous rencontriez encore des difficultés (y'a pas de raisons mais ça arrive), pas de problèmes nous avons conçu cet atelier pour qu'il soit régulier et porté également sur le support, l'aide aux nouveaux utilisateurs. Donc notez vos questions, vos problèmes dans un coin, et repassez nous voir la semaine suivante ! (vous pourrez également nous poser des questions sur IRC (chat) ou sur la mailling liste, si vous ne pouvez pas attendre)

    En espérant libérer un maximum de vos machines !

    [FR Bordeaux] Atelier artiste - hacker - Le mercredi 5 juillet 2017 de 19h00 à 21h00.

    Ateliers-cours à la fabrique-pola - L@bx

    Tous les mercredi, 19h00, à partir du 07 décembre 2016

    Passer aux logiciels libres pour toute sa pratique artistique :
    graphisme, édition, site internet, photo, vidéo, 3D, dossiers, imprimerie, son, installations multimédia…

    Reprendre le contrôle de sa vie privée
    Chiffre ses emails, échapper aux GAFAM'S, se débarrasser des pubs, surfer avec tor, mettre en place un VPN…

    S'approprier, détourner, contourner
    Les machines physique et langagière, les espaces publics, les symboles, les techniques….

    + Quelques notions et référence sur l'histoire du hack…

    Matériel : clé usb, pc portable (si possible).

    [FR Chartres] OpenAtelier - Le mercredi 5 juillet 2017 de 20h00 à 23h59.

    L'OpenAtelier est un moment de rencontre et de partage ou les membres et curieux sont invités à échanger sur leurs idées et leurs projets.

    Les espaces techniques sont également ouverts aux réalisations (électronique, informatique, menuiserie, impression 3D, découpe vinyle…).

    Pour les curieux, c'est le bon moment pour venir découvrir l'association et ses membres.

    [FR Toulouse] Rencontre Tetalab - Le mercredi 5 juillet 2017 de 21h00 à 23h00.

    Rencontre hebdomadaire des hackers et artistes libristes Toulousains.

    [FR Saint-Étienne] Photo souvenir RMLL - Le jeudi 6 juillet 2017 de 12h30 à 12h45.

    Une photo souvenir des RMLL2017 sera faite sur le stand fsfe du village du libre. Viendez.

    [FR Poitiers] Jeudi du Libre - Le jeudi 6 juillet 2017 de 17h30 à 20h30.

    Comme chaque premier jeudi du mois, les membres de l’APP3L se réunissent au Centre Régional d’Information Jeunesse (CRIJ).

    Et vous invitent à les rejoindre, de 17h30 à 20h30, afin d'échanger et d'en apprendre plus à propos des logiciels libres.

    Si vous le désirez, vous pouvez venir avec votre ordinateur portable ou fixe (nous prêterons écrans, claviers et souris).

    Cette permanence est l’occasion pour chacun de :

    • rencontrer d'autres utilisateurs.
    • de discuter ou de s’informer.
    • de trouver de l’aide (vous pouvez amener votre machine).
    • ou tout simplement de découvrir.

    Entrée Libre. Tout Public.

    Accès 64 rue Léon Gambetta 86000 Poitiers

    [FR Grenoble] Wikipédia : initiez-vous à la contribution - Le jeudi 6 juillet 2017 de 18h30 à 21h00.

    Ce jeudi 6 juillet, les Wikipédiens de Grenoble se réunissent et vous accueillent pour une soirée conviviale et instructive.

    Que vous soyez déjà contributeur ou simple curieux, venez discuter de Wikipédia, apprendre à contribuer, élaborer ensemble des projets d’articles, vous renseigner sur les événements Wikipédia à venir, ou simplement rencontrer d’autres passionnés pour échanger autour de la connaissance libre sur internet.

    Entrée libre de 18h30 à 21h, buffet et boissons offerts par la Fondation Wikimédia.

    Sur inscription

    [FR Le Mans] Autour d'un verre autour du Libre - Le jeudi 6 juillet 2017 de 19h00 à 23h00.

    Libristes, hackers, pasionnés ou néophites, ou même simplement curieux, voici venu le 1er jeudi du mois.

    Le HAUM (Hackerspace AU Mans) et LinuXMaine (Association de promotion du logiciel libre en Sarthe) vous donnent rendez-vous "autour d'un verre autour du libre", à partir de 19h à l'épicerie du pré, 31 Rue du Pré, 72100 Le Mans.

    En mode free, à partir de 19h, vous pouvez venir accompagné, avec des bidouilleries, avec de la presse spécialisée, avec un ordi, avec des questions, avec votre curiosité, etc…

    [FR Paris] Soirée de Contribution au Libre - Le jeudi 6 juillet 2017 de 19h00 à 22h00.

    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 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.

    En cas de difficulté, vous pouvez joindre un des responsables de la soirée, Emmanuel Seyman (emmanuel (at) seyman.fr), Paul Marques Mota mota (at) parinux.org, ou Magali Garnero (Bookynette) tresorier (at) parinux.org.

    Pour obtenir le code d'entrée de la porte cochère, envoyez un mail au responsable.

    On peut amener de quoi se restaurer (Franprix, 8 rue du Chemin Vert, ferme à 22h)

    Regazouillez sur Twitter - Wiki des soirées

    Programme non exhaustif

    • Fedora (sa traduction)
    • Parinux, ses bugs et son infrastructure
    • April, … y a toujours quelque chose à faire
    • Open Food Facts/ Open Beauty Facts, sa base de données, ses contributeurs, sa roadmap
    • Schema racktables, son code
    • Agenda du Libre, mise à jour et amélioration du code
    • Ubuntu-Fr, son orga, ses événements
    • En vente libre, maintenance et commandes
    • Open street map, une fois par mois
    • Linux-Fr sait faire

    tout nouveau projet est le bienvenu.

    [FR Paris] PolyConf 17 - Du vendredi 7 juillet 2017 à 08h00 au dimanche 9 juillet 2017 à 19h00.

    PolyConf est une conférence pour échanger sur les meilleures pratiques de la programmation.

    Les programmeurs sont trop souvent réduits à un langage de programmation alors qu’il est plus sage, dans un contexte d’innovation constante, d’apprendre à apprendre et de combiner le meilleur de chaque langage dans des solutions ad hoc. Autrement dit, le fait de ne pas se spécialiser en tant que développeur sur un langage spécifique, pour préférer une approche polyvalente.

    Concrètement, cela s'est reflété dans le programme de l'événement qui a traité de nombreux sujets Ruby, Python, Haskell, Rust, Erlang, Go, Java, F#, Javascript, …

    [QC Montréal] CLA - Évènement festif du Libre au Jardin Botanique - Le vendredi 7 juillet 2017 de 16h00 à 20h00.

    Le Club Linux Atomic
    Le Club Linux Atomic (CLA) regroupe des utilisateurs, novices comme aguerris, de systèmes d’exploitation GNU/Linux et de logiciels libres. Il a pour principal objet de mieux faire connaître l’informatique libre et d’en favoriser l’utilisation par le plus grand nombre.
    La programmation de la rencontre

    [FR Strasbourg] Réunion mensuelle ouverte d'ARN - Le vendredi 7 juillet 2017 de 18h00 à 22h00.

    ARN vous accueil un vendredi par moi pendant le Stammtisch du Hackstub !

    Dans ces réunions :
    • nous accueillons des visiteur-se-s qui veulent en savoir plus sur notre démarche ou apprendre à nous connaître ;
    • nous évoquons les sujets actuels relatifs à l'association et au numérique autour de Strasbourg ;
    • nous faisons le point tous-toutes ensemble sur l'avancée des projets de l'association et des projets associatifs environnants ;
    • nous profitons de ces instants pour faire avancer les projets de l'association sous forme de groupes de travail ouverts.

    Ces réunions se concluent par un repas convivial à l'extérieur.
    Ces réunions sont ouvertes à tout le monde, membre d'ARN ou non. Pas d'inscription préalable.

    N'hésitez pas à venir échanger avec nous !

    [FR Le Tholonet] Réunion mensuelle de l'Axul - Le vendredi 7 juillet 2017 de 20h00 à 23h55.

    Les membres de l'Axul (Association du Pays d'Aix des Utilisateurs de Linux et des Logiciels Libres) vous invitent à leur réunion mensuelle qui aura lieu le vendredi 7 juillet de 20h00 à 23h55 au 1er étage du centre culturel Georges Duby du Tholonet (859 avenue Paul Julien, à proximité de la place du marché) à Palette, premier village sur la D7n au Sud-Est d'Aix.

    Ordre du jour

    • 20h00 - 20h15 : Accueil
    • 20h15 - 20h30 : Présentation des participants et organisation de la soirée
    • 20h30 - 22h30 : Préparation des projets 2017-2018 sur le thème de la sécurité
    • 22h30 - 23h55 : Discussion générale
      • Compte rendu du Samedi Libre du 1 juillet
      • Compte-rendu des RMLL 2017 à Saint-Étienne du samedi 1er juillet au vendredi 7 juillet
      • Assogora 2017: dimanche 10 septembre
      • Autres interventions de l'Axul…
      • Information sur les ateliers : Arduino, Raspberry Pi…
      • Autres questions ?

    Événements ultérieurs

    • Samedi Libre du 2 septembre 2017
    • Assogora 2017: dimanche 10 septembre 2017

    La plupart des réunions donnent lieu à une présentation ou à une démonstration liée au Logiciel libre.

    Ces réunions libres et gratuites sont ouvertes à toutes et à tous, débutant(e)s ou expert(e)s GNU/Linux, membres ou non de l'Axul.

    Entrée Libre. Tout Public.

    [FR Valenciennes] Permanence ValLibre - Le samedi 8 juillet 2017 de 09h30 à 12h00.

    Permanence assistance informatique.

    Dépannage petits bobos informatiques.

    Initiation à l'informatique libre.

    Tous les samedis ouvrables sauf les derniers samedis du mois et les samedis en période de vacances scolaires.

    Si besoin particulier, la prise de rendez-vous est fortement conseillée.

    Téléphone accueil MQCV : 03 27 22 43 90

    [FR Courbevoie] Atelier langage ADA - Le samedi 8 juillet 2017 de 09h30 à 18h30.

    L'association StarinuX, promotrice du logiciel Libre et Opensource, vous convie à l'atelier :

    LANGAGE Ada,

    QUAND: le samedi 8 juillet 2017 de 9h30 à 18h30

    : 48 rue de Colombes 92400 Courbevoie (Gare Courbevoie, SNCF St Lazare <=> La Défense ou RATP bus 275, Pont de Levallois <=> La Défense, arrêt STADE.

    PRÉSENTATION :

    Son nom vient de Ada Lovelace, pionnière de la science informatique.

    Ada est un langage de programmation inventé par une équipe de CII-Honeywell Bull, orienté objet dont les premières versions remontent au début des années 1980. Il est souvent utilisé dans des systèmes temps réel et embarqués nécessitant un haut niveau de fiabilité et de sécurité. De nos jours, Ada est employé dans toutes les technologies de pointe : en France, l'automobile, les transports ferroviaires (ALSTOM, Siemens Transportation Systems, ANSALDO-STS, TGV, Corail, RER, METEOR), les technologies aéronautiques (Thales, Airbus, EADS-Défense) et les technologies spatiales (Thales Alenia-Space, EADS-Astrium, CNES, Arianespace), le nucléaire (CEA)…

    OBJECTIF:

    Ada est un langage du présent et de l'avenir. Apprenez à programmer vos premières applications en langage ADA. Des experts de l'association Ada-France, formateurs de cet atelier, vous encadreront pendant les exercices.

    PROGRAMME:

    Plusieurs exercices encadrés par 4 à 5 membres d'Ada-France et ingénieurs :

    • Calcul du nombre Pi (séquentiel) (nouveau),
    • Calcul du nombre d'Or,
    • Horloge apériodique,
    • Le zoo,
    • Traitement d'images.
    • Calculer le nombre Pi (calcul //) (nouveau).

    MODALITÉS - PRÉ-REQUIS - NIVEAU:

    Les débutants en Ada sont acceptés.

    Pour profiter au mieux de cet atelier, il est fortement recommandé d'avoir des connaissances de base en programmation. Nécessité impérative d'avoir un Linux 64 bits, sinon de l'installer en mode virtuel, car le compilateur Ada ne fonctionne qu'en 64 bits.

    FORMATEURS: atelier animé par des membres d'Ada-France.

    PRÉCISION: comme à l'accoutumée, une participation de 20€ (10€ demandeurs d'emploi) / ANNUEL est demandée.

    INFOS et INSCRIPTION: https://www.starinux.org/ateliers-sx.php

    [CH Pully] Pully.INTERGEN.digital - Le samedi 8 juillet 2017 de 10h00 à 17h00.

    Entraide numérique de 7 à 107 ans

    Les enfants sont associés aux parents, aux informaticiens bénévoles, et aux seniors, pour assurer une entraide numérique intergénérationnelle mensuelle.

    Bien souvent, nos "digital naïfs", heu pardon, nos "digital natifs" sont souvent bien plus appropriés pour expliquer simplement à nos seniors, le fonctionnement d'un Smartphone, explorer des jeux sympas (là ils sont trop forts… ;)

    Que ce soit pour faire son Ebanking, une réservation, dépatouiller un truc, ou explorer de nouvelles possibilités, au lieu de le faire tout seul chez soi, autant s'y mettre à plusieurs. D'autant que si les formations c'est bien, la mise en pratique après, c'est parfois un peu "galère"… Alors qu'avec un "junior" sous la main, c'est souvent débloqué en 5 minutes (4 minutes pour le sortir de son jeux et attendre la fin de la "partie en cours", et 1 minute pour débloquer le truc…Patience, il va venir)

    Combien cela coûte ? Rien du tout ! Le local et électricité sont offerts par la coopérative d’habitation des Liaudes Le WiFi par le président de CloudReady.ch, et repas et boissons par vous Qui venez avec un peu, à boire et à manger, avec vos propres équipements informatiques, si possible, sinon sans, on t’en prêtera.

    • Tu viens quand tu peux,

    • tu repars quand tu veux,

    • tu feras ce que tu pourras, et dans la bonne humeur ;-)

    Mais on fait aussi des trucs cool, comme "PC revival" car on peut faire du numérique en récupérant les vieux portables Windows XP, pour les faire "revivre" sous Linux Facile !

    Aussi des "Mapathon", et tu peux venir découvrir "OpenStreetMap" et MissingMaps.org

    • Cf. http://pully.intergen.digital

    C'est simple, c'est facile à faire !

    Tu voudrais la même chose dans ta commune ? Fais-le :)

    http://intergen.digital

    [FR La Couronne] Permanence - accueil public - Le samedi 8 juillet 2017 de 10h00 à 13h00.

    Notre permanence d'accueil avec le sourire, le café et les gâteaux !

    Lieu de rencontre et d'échange convivial pour discuter informatique et outils numériques.

    Cette association permet à chacun de découvrir également l'univers de Linux et par extension de tous les **logiciels* et matériels libres*.

    Entrée Libre. Tout Public.

    [FR Morogues] Atelier libre - Le samedi 8 juillet 2017 de 10h00 à 12h00.

    Ateliers d'entraide informatique & bricolages divers

    Vous souhaitez apprendre à réparer votre ordinateur De l'aide pour installer votre premier linux 

    Vous souhaitez aller plus loin avec un ordinateur et héberger vos outils Un coup de main pour finir un montage électronique

    [FR Strasbourg] Décentraliser ses usages numériques - Le samedi 8 juillet 2017 de 14h00 à 18h00.

    Lors de cet atelier, des bénévoles d’Alsace Réseau Neutre et d’autres associations, vous proposent de reprendre le contrôle sur vos données numériques en vous accompagnant dans l’adoption de solutions alternatives à vos usages numériques courants.

    Concrètement, il s’agit de vous aider à :

    • Configurer votre navigateur pour limiter les données transmises à votre insu
    • Découvrir des services numériques éthiques
    • Installer Linux ou LineageOS (Install Party)
    • Prendre en main une solution d’auto-hébergement qui vous permet d’avoir votre propre cloud de fichier, d’héberger votre site web ou encore vos mails (La brique Internet / YunoHost)

    Tout public
    Gratuit (dons acceptés)
    Inscriptions : contact@arn-fai.net, contact.shadok@strasbourg.eu

    [FR Strasbourg] AG d'Alsace Réseau Neutre - Le dimanche 9 juillet 2017 de 12h00 à 20h00.

    L'AG d'Alsace Réseau Neutre se déroulera le dimanche 9 juillet et aura lieu au 7 rue de la Rheinmatt 67100 STRASBOURG.

    Si il fait beau l'AG aura lieu sur le carré d'herbe à côté, on se débrouillera pour acheminer le réseau (à 10m ça devrait le faire). Si il pleut ou froid, il faudra sonner à "GRIMAUD".

    Le programme n'est pas encore clair, mais en gros on propose un picnic à partir de 12h puis on attaquera les sujets à partir de 14h.

    Pour participer à la conception du programme, ça se passe ici http://pad.arn-fai.net/p/AG2017

    N'hésitez pas, l'AG sera ce que nous en ferons :)

    Si vous êtes membres vous pouvez donner procuration à un autre membre en envoyant un mail au CA et au membre concerné. Un membre ne peux pas avoir plus de 3 procurations. Si vous n'êtes pas membre, vous pouvez quand même participer, mais vous ne serez pas comptabilisé dans les votes.

    L'heure de fin n'est pas définie.

    Télécharger ce contenu au format Epub

    Lire les commentaires

    Sortie de Replicant 6.0

    2 juillet, 2017 - 11:31

    Replicant est un système d’exploitation entièrement libre pour mobiles/tablettes, pilotes et micro‐logiciels compris. Puisqu’il y a une claire volonté de faire du 100 % libre, il y a peu d’appareils pris en charge. De plus, pour ceux qui le sont, ils ne le sont que partiellement et tous les périphériques ne fonctionnent pas (à moins d’installer du logiciel privateur). Cette pureté éthique en fait un système que la FSF (Free Software Foundation) apprécie et que la FSFE (Free Software Foundation Europe) recommande dans sa campagne Libérez votre Android !.

    Sommaire Replicant plus en détails

    Il est basé sur Android, ou plus exactement AOSP (Android Open Source Project). Il n’est pas pour autant directement basé sur AOSP, en effet chaque version se base sur une version modifiée d’AOSP (comme CyanogenMod et LineageOS). Il va de soi qu’il ne contient pas les applications privatrices de Google (qui prennent peu à peu la place de celles libres de AOSP).

    Par défaut, il n’y a donc ni Google Play Store, ni Amazon AppStore. Néanmoins, F-Droid est préinstallé. C’est un gestionnaire d’applications libre avec une interface graphique (qui sera bientôt changée). Par défaut, la seule source d’applications est celle de f-droid.org, qui ne contient que des logiciels libres ou presque (ce qui pose problème à Replicant qui souhaite respecter les recommandations pour les distributions de systèmes libres de la FSF). Cependant, il est possible de rajouter et créer d’autres sources, par exemple via le paquet fdroidserver de Debian.

    La version 6.0

    Le 13 mars 2017, Replicant a annoncé la sortie de la version 6.0. La dernière était Replicant 4.2.0004, et la première version de cette « branche » était sortie 22 janvier 2014, ce qui faisait trois ans sans mise à jour, hormis pour la sécurité et la stabilité, mais vous pouvez faire un ou des dons via la FSF si vous souhaitez encourager le projet et que ça avance plus vite.

    Comme on peut le deviner Replicant 4.2 est basé sur AOSP 4.2 et la version 6.0 sur AOSP 6.0 (« Marshmallow »). Replicant a donc sauté de nombreuses versions (4.3, 4.4, 5.0 et 5.1). Cela n’a rien de surprenant, avant Replicant 4.2, il y a eu la 4.0 et donc pas de 4.1. Cependant, le cas de l’écart de version entre Replicant 2.3 et Replicant 4.0 est différent, puisque le code de la version 3 (d’AOSP) n’a été rendu publique et libre qu’à la publication de la version 4.0 (qui a pour nom Ice Cream Sandwich).

    Au moins depuis la version 2.3, Replicant se basait sur CyanogenMod (à ne pas confondre avec Cyanogen OS), qui était le dérivé d’AOSP, en grande partie libre le plus populaire, et qui gérait beaucoup de matériels (ce qui était facilité par l’acceptation de code et binaires privateurs). Fin 2016, CyanogenMod est mort et a été forké sous le nom de LineageOS. Avant cet événement, il a été envisagé d’utiliser OmniROM à la place. Finalement, c’est LineageOS 13.0 qui a été retenu pour Replicant 6.0.

    Cette nouvelle version prend en compte (pour l’instant) moins d’appareils que la précédente : Galaxy S2 (I9100), Galaxy S3 (I9300) et Galaxy Note 2 (N7100). Il n’y a donc pour l’instant que des appareils Samsung qui sont gérés. De plus, il y a une gestion partielle du Galaxy S3 4G (I9305), qui n’était géré par aucune version précédente, mais il n’est pas encore possible de téléphoner et utiliser Internet via le réseau téléphonique avec cette version de Replicant pour cet appareil. C’est néanmoins une priorité de gérer plus d’appareils, et il est affirmé que le GTA04, le Galaxy Nexus (I9250), la Galaxy Tab 2 7.0 (P31xx), la Galaxy Tab 2 10.1 (P51xx), et le Galaxy Note 1 (N7000) seront pris en charge.

    Les personnes derrière Replicant ont profité de cette mise à jour majeure pour nettoyer et enrichir le wiki.

    La procédure d’installation n’a pas l’air d’avoir changé (hormis le passage de MD5 à SHA-256 pour vérifier les binaires). Si vous êtes allergiques à l’anglais et/ou que vous voulez des astuces post‐installation, Nicola Spanti a fait un tutoriel en français pour expliquer comment installer Replicant 6.0 sur le Galaxy S3 (I9300). Si vous cherchez des applications et/ou services pour remplacer ceux de Google et qui soient de préférence libres, il a fait un article sur le sujet qu’il continue de mettre à jour (et auquel vous pouvez contribuer si vous savez utiliser git et GitLab).

    Pas de SDK pour la version 6.0 !

    Il n’y aura pas de SDK (kit de développement) pour Replicant 6.0, alors qu’il y en avait eu pour trois versions (2.2, 4.0 et 4.2). Le SDK fourni par Google contient malheureusement des licences privatrices et incite à installer des modules complémentaires propriétaires (par exemple, pour les API de Google), ce qui avait poussé à fournir un SDK libre. Le code du SDK est libre, il fallait donc « juste » arriver à le compiler.

    Depuis quelque temps, le SDK d’Android est disponible dans Debian (via le paquet android-sdk), à partir de la version 9 "Stretch" (sortie le 17 juin 2017). Cela permet apparemment de compiler certaines applications, mais il manquerait des bibliothèques libres pour certaines (celles privatrices ne sont donc pas comptées ici). Le SDK fourni par Debian correspond à Android 6.0, donc à la même API que ce dernier. Puisque Debian fait de beaux paquets et a une équipe dédiée, Replicant ne fournit pas de nouvelle version du SDK et n’aura probablement plus jamais à en fournir, ce qui permet aux personnes derrière Replicant de se concentrer sur d’autres choses et évite de disperser les forces du Libre. Debian peut être jugé problématique si on veut proposer un système entièrement libre à des personnes pas ou peu au fait du logiciel libre, on peut donc juger souhaitable qu’il y ait des paquets (pour le SDK d’Android) dans des distributions 100 % libres (comme Parabola GNU/Linux-libre et Trisquel GNU/Linux qui aura un support au moins partiel dans sa version 8) (sans pour autant nécessairement penser que Debian est à jeter à la poubelle, la FSF a, par exemple, fait un partenariat avec Debian sur h-node).

    Journal des modifications Modifications indépendantes de l’appareil
    • nouvelle application RepWifi pour l’usage des adaptateurs Wi‐Fi ;
    • possibilité de sélectionner llvmpipe comme un compositeur logiciel alternatif (il faut pour l’instant passer par la ligne de commande) ;
    • le scan de QR-Code fonctionne ;
    • possibilité d’accéder à la caméra depuis l’écran de déverrouillage ;
    • GCC, Binutils, Clang, Jack, Jill et d’autres parties de la chaîne de construction sont construits depuis les sources ;
    • suppression de la dépendance à des outils pré‐construits ;
    • correction pour la construction sur Debian 9 Stretch (l’actuelle stable) ;
    • miroir du code source de LineageOS et utilisation d’étiquettes pour tous les dépôts ;
    • nouveau script pour générer les clés et signer les images avec vos propres clés ;
    • possibilité de définir des mots de passe différents pour le chiffrement et l’écran de déverrouillage ;
    • ajout de l’extension pour que F-Droid ait les privilèges système ;
    • désactivation de la vérification du portail captif qui se connecte à un serveur Google ;
    • configuration du noyau (Linux) renforcée ;
    • mise à jour de Heimdall (qui sert à « flasher » des appareils Samsung et est disponible dans Debian) ;
    • plusieurs améliorations pour la vie privée dans le navigateur Web (désactivation du préchargement et de fonctionnalités de pistage) ;
    • les aperçus fonctionnent dans l’application galerie ;
    • ADB (Android Debug Bridge) est désactivé par défaut ;
    • apposition de la « marque » Replicant sur le recovery et DEX Optimizer ;
    • ajout d’un nouveau fond d’écran.
    Galaxy S2 (I9100)
    • les graphismes en 2D fonctionnent (rapidement) ;
    • le son marche, mais pas en Bluetooth ou via USB ;
    • la partie téléphonie est fonctionnelle, à la fois pour téléphoner et pour l’accès à Internet ;
    • la puce Wi‐Fi interne ne marche pas sans micro‐logiciels privateurs, mais les périphériques Wi‐Fi externes avec un AR9271 fonctionnent ;
    • le Bluetooth ne marche pas sans micro‐logiciels propriétaires ;
    • les capteurs marchent ;
    • la caméra fonctionne ;
    • il n’y a pas de codage et de décodage matériel de médias sans micro‐logiciels privateurs.
    Galaxy S3 (I9300)
    • les graphismes en 2D fonctionnent ;
    • le son marche ;
    • la partie téléphonie est fonctionnelle, à la fois pour téléphoner et pour l’accès à Internet ;
    • la puce Wi‐Fi interne ne marche pas sans micro‐logiciels privateurs, mais les périphériques Wi‐Fi externes avec un AR9271 fonctionnent ;
    • le Bluetooth ne marche pas sans micro‐logiciels propriétaires ;
    • le NFC (Near Field Communication) fonctionne ;
    • les capteurs marchent ;
    • la caméra arrière marche, mais pas celle côté face, du moins pas sans micro‐logiciel privateur ;
    • le codage et le décodage matériel de médias ne fonctionnent pas sans micro‐logiciels privateurs.
    Galaxy Note 2 (N7100)
    • les graphismes en 2D fonctionnent ;
    • le son marche ;
    • la partie téléphonie est fonctionnelle, à la fois pour téléphoner et pour l’accès à Internet ;
    • la puce Wi‐Fi interne ne marche pas sans micro‐logiciels privateurs, mais les périphériques Wi‐Fi externes avec un AR9271 fonctionnent ;
    • le Bluetooth ne marche pas sans micro‐logiciel propriétaire ;
    • le NFC (Near Field Communication) fonctionne ;
    • les capteurs marchent (les pilotes ont été mis à jour pour fonctionner avec des micro‐logiciels plus récents) ;
    • la caméra arrière marche, mais ce n’est pas le cas de celle côté face du moins pas sans micro‐logiciel privateur.
    Galaxy S3 4G (I9305)
    • les graphismes en 2D fonctionnent ;
    • le son marche ;
    • la puce Wi‐Fi interne ne marche pas sans micro‐logiciel privateur, mais les périphériques Wi‐Fi externes avec un AR9271 fonctionnent ;
    • le Bluetooth ne marche pas sans micro‐logiciel propriétaire ;
    • le NFC (Near Field Communication) fonctionne ;
    • les capteurs marchent ;
    • la caméra arrière marche, mais ce n’est pas le cas de celle à l’avant sans micro‐logiciel privateur ;
    • le codage et le décodage matériel de contenus audiovisuels ne fonctionnent pas sans micro‐logiciels privateurs.
    Informations sur les appareils actuellement pris en charge par cette version Acquisition d’un appareil

    Les appareils pris en charge ne sont pas récents. Néanmoins, c’étaient des modèles connus qui ont été vendus à plusieurs millions d’exemplaires. Il devrait donc être relativement aisé de les trouver en occasion (via des sites Web de particulier à particulier, des magasins spécialisés dans l’occasion, etc.). Technoethical propose certains modèles reconditionnés avec Replicant pré‐installé (actuellement le S2, le S3 non 4G, et le Note 2) et écrit donner 10 % des profits sur la vente d’un appareil (sous Replicant) au projet Replicant.

    Samsung Galaxy S2 (I9100)
    • dimension : 125,3 × 66,1 × 8,5 mm (4,93 × 2,60 × 0,33”) ;
    • masse : 116 g (4,09 oz) ;
    • SIM : mini-SIM, seulement GSM (CDMA n’est pas géré) ;
    • écran : Super AMOLED Plus, 16 millions de couleurs, 4,3 pouces en taille, résolution 480 × 800 px, multi‐tactile (LD9040) ;
    • processeur principal : double-cœur à 1,2 GHz Cortex-A9 ;
    • mémoire : 1 Gio de mémoire vive, 16 Gio ou 32 Gio de stockage interne, un port pour carte microSD pouvant aller jusqu’à 32 Gio ;
    • appareil photo arrière : 8 méga-pixels, 3 264 × 2 448 px, auto-focus, flash LED (Fujitsu M5MO) ;
    • appareil photo avant : 2 méga-pixels (Samsung S5K5BAFX) ;
    • audio : prise jack 3,5 mm TRRS ;
    • radio : radio FM stéréo (SI4709) ;
    • NFC (PN544) ;
    • capteurs : accéléromètre (K3DH), gyroscope, proximité (CM3663), boussole (AKM8975) ;
    • batterie : Li‐Ion 1 650 mAh ;
    • des micro‐logiciels privateurs ;
    • système privateur pour le modem ;
    • système d’amorçage (bootloader) propriétaire et signé ;
    • sortie en mai 2011 (en tant que haut de gamme).
    Samsung Galaxy S3 (I9300)
    • dimension : 136,6 × 70,6 × 8,6 mm (5,38 × 2,78 × 0,34”) ;
    • masse : 133 g (4,69 oz) ;
    • SIM : Mini-SIM, seulement GSM (CDMA n’est pas géré) ;
    • écran : Super AMOLED, 16 millions de couleurs, 4,8 pouces en taille, résolution 720 × 1280 px, multi‐tactile ;
    • processeur principal : quatre cœurs à 1,4 GHz Cortex-A9 (Samsung Exynos 4412) ;
    • carte graphique : Mali 400 MP4 ;
    • mémoire : 1 Gio de mémoire vive, 16 Gio ou 32 Gio de stockage interne, un port pour carte microSD pouvant aller jusqu’à 64 Gio ;
    • appareil photo arrière : 8 Mpx, 3 264 × 2 448 px, f/2,6, auto-focus, flash LED (S5C73M3) ;
    • appareil photo avant : 1,9 Mpx (S5K6A3) ;
    • audio : prise jack 3,5 mm TRRS ;
    • radio : radio FM stéréo avec RDS ;
    • NFC (dans la batterie) (PN544) ;
    • capteurs : accéléromètre (LSM330DLC), gyroscope (LSM330DLC), proximité (CM36651), boussole (AKM8975), baromètre (LPS331AP) ;
    • batterie : Li‐Ion 2 100 mAh, peut être retirée facilement (pas de vis, etc.) ;
    • des micro‐logiciels privateurs ;
    • système privateur pour le modem, mais il semble isolé ;
    • système d’amorçage (bootloader) propriétaire et signé ;
    • sortie en mai 2012 (en tant que haut de gamme).
    Samsung Galaxy Note 2 (N7100)

    C’est essentiellement un I9300 mais en plus grand

    • dimension : 151,1 × 80,5 × 9,4 mm (5,95 × 3,17 × 0,37”) ;
    • masse : 183 g (6,66 oz) ;
    • SIM : mini-SIM, seulement GSM (CDMA n’est pas géré) ;
    • écran : Super AMOLED, 16 millions de couleurs, 5,5 pouces en taille, résolution 720 × 1 280 px, multi‐tactile ;
    • processeur principal : quatre cœurs à 1,1 GHz Cortex-A9 (Samsung Exynos 4412) ;
    • carte graphique : ARM Mali-400MP4 ;
    • mémoire : 2 Gio de mémoire vive, 16 Gio ou 32 Gio ou 64 Gio de stockage interne, un port pour carte microSD pouvant aller jusqu’à 64 Gio ;
    • appareil photo arrière : 8 Mpx, 3 264 × 2 448 px, f/2,2, autofocus, flash LED ;
    • appareil photo avant : 1,1 Mpx ;
    • audio : prise jack 3,3 mm TRRS ;
    • radio : radio FM stéréo avec RDS ;
    • NFC ;
    • capteurs : accéléromètre, gyroscope, proximité, boussole, baromètre ;
    • batterie : Li‐Ion 3 100 mAh, peut être retirée facilement (pas de vis, etc) ;
    • des micro‐logiciels privateurs ;
    • système privateur pour le modem ;
    • système d’amorçage (bootloader) propriétaire et signé ;
    • sortie en septembre 2012 (en tant que haut de gamme).
    Samsung Galaxy S3 4G (I9305)

    Comme son nom l’indique, c’est essentiellement un I9300 avec du 4G LTE :

    • écran : Super AMOLED, 16 millions de couleurs, 4,4 pouces en taille, résolution 720 × 1 280 px, multi‐tactile, Corning Gorilla Glass 2 ;
    • processeur principal : Samsung Exynos 4412 ;
    • carte graphique : Mali 400 ;
    • NFC (PN544) ;
    • modem : Qualcomm MDM9615 (aussi utilisé dans l’iPhone 5) ;
    • capteurs : accéléromètre (LSM330DLC), gyroscope (LSM330DLC), proximité (CM36651), boussole (AKM8975), baromètre (LPS331AP) ;
    • appareil photo arrière : 8 Mpx, 3 264 × 2 448 px, f/2,2, autofocus, flash LED (puce S5C73M3) ;
    • appareil photo avant : 1,1 Mpx (puce S5K6A3) ;
    • sortie en septembre 2012 (en tant que haut de gamme).
    Changements constatés entre la version 4.2 0004 et 6.0 0001 sur Galaxy S3 (I9300)
    • le recovery a changé : il est « brandé » (il est en rouge, la couleur de Replicant, et a le logo de Replicant) et il gère le tactile (avec celui de la version 4.2 0004, il n’y avait que les touches physiques qui marchaient) ;
    • le logo de démarrage a subtilement changé : il est plus petit ;
    • l’aperçu des applications en pause (qui s’obtient avec un appui long sur la touche « maison » centrale du Galaxy S3) ne marche plus ;
    • la capture d’écran (appui simultané sur le bouton physique volume moins et celui « power ») ne marche plus : ça a soi-disant marché, mais l’image est noire. Le problème est connu et documenté ;
    • l’application capture a un fond mal dégradé dans sa partie basse ; elle semble pourtant n’avoir pas changé, alors qu’il n’y avait pas ce léger bogue graphique avec la version 4.2 ;
    • la musique de la carte microSD n’était plus trouvée. Il faut renommer le dossier (contenant la musique) pour que l’application Musique retrouve ses petits, entraînant probablement une indexation par Android (laquelle aurait du être faite à l’insertion de la carte) ;
    • il n’y a plus d’application lampe (de poche), qui allume la LED de l’appareil photographique, mais il y a des applications libres pour y remédier sur F-Droid ;
    • l’interface graphique semble plus lente.
    Télécharger ce contenu au format Epub

    Lire les commentaires

    Sixième édition de la LDAPCon à Bruxelles en octobre 2017

    28 juin, 2017 - 23:30

    Opensides annonce l’organisation de la 6e édition de la LDAPCon, le jeudi 19 et vendredi 20 octobre 2017 au Mundo-b à Bruxelles.

    Cette conférence internationale sur LDAP et plus largement sur les questions de gestion des identités, d’authentification et d’habilitation, est l’occasion de rencontrer les acteurs les plus importants du domaine.

    Développeurs d’annuaires et d’outils de gestion, intégrateurs reconnus et utilisateurs avancés partagent beaucoup d’informations en deux jours, faisant ainsi le point sur l’activité de la communauté et permettant de s’assurer que celle‐ci est bien vivante.

    Parmi les thèmes traités, on retrouve :

    • technologie LDAP (serveurs, interfaces de programmation, interfaces utilisateur, etc.) et son implémentation ;
    • utilisation de LDAP (schémas, sécurité, opérations, big data, etc.) ;
    • technologies LDAP (PKI, XACML, SAML, etc.) ;
    • meilleures pratiques pour les services d’annuaire.

    Le prix du ticket d’entrée est de 250 € (200 € pour toute inscription avant le 15 août 2017), ce qui donne accès à toutes les sessions de conférences, aux repas de midi et dîner de gala du 19 octobre et un accès anticipé aux diapos des présentations. Il existe également un tarif étudiant à 50 € (le dîner de gala n’est pas inclus).

    Télécharger ce contenu au format Epub

    Lire les commentaires

    Un pas en avant pour les serveurs libres : le projet NERF

    28 juin, 2017 - 18:22

    Avons‐nous une chance d’avoir un code plus ouvert pour nos serveurs préférés ?

    Coreboot (né LinuxBIOS) a fonctionné durant ses sept premières années sur serveurs, mais il n’est malheureusement plus disponible sur serveurs x86 aujourd’hui ! La faute aux blobs binaires obligatoires pour initialiser la machine, pour lesquels nous n’avons pas d’autorisation de redistribution — voire pas de blobs du tout.
    C’est là qu’entre en jeu le projet NERF (Non‐Extensible Reduced Firmware), un autre fils de Ron Minich, déjà père de LinuxBIOS et Coreboot. Ron n’a pas peur des idées folles, et il voudrait contourner les blobs avec un noyau Linux (et ses pilotes !) dans le BIOS.

    Sommaire

    Comme la plupart d’entre vous le savent, je suis un grand supporteur des serveurs libres, pour de multiples raisons que je ne vais pas réexpliquer dans ce journal aujourd’hui. Beaucoup d’entre vous m’ont « challengé » ces derniers mois sur la notion d’ouverture réelle des serveurs libres, et je vous ai longtemps répondu que le monde du logiciel libre ne s’était pas construit en un jour.
    C’est la même chose pour le matériel libre, et cela explique pourquoi je suis aujourd’hui plus impliqué dans le développement des outils nécessaires à faire du matériel, plutôt qu’à développer du matériel. J’aime l’analogie qui consiste à dire que développer Linux avec des outils propriétaires serait un non‐sens.

    C’est pourquoi je suis un contributeur actif au projet FreeCAD, un utilisateur de KiCAD, et n’avais jusqu’à présent que peu de temps pour me pencher sur la problématique des BIOS. Toutefois, FreeCAD s’améliorant (notamment la version de développement), il est de plus en plus proche d’un statut suffisant pour développer la mécanique d’un serveur. Aussi ai‐je décidé de me ré‐intéresser au sujet des BIOS, que j’avais quitté il y a bien longtemps. J’ai donc constitué mon baluchon et en route pour Denver à ma première conférence Coreboot. Pas forcément à côté de la maison, mais les présentations furent fort intéressantes et effectuées par des contributeurs aguerris du projet.

    Coreboot inopérant

    Coreboot est le « fils » du projet linuxbios, initié par Ron Minnich à Los Alamos. Ron travaille actuellement chez Google. Coreboot est un BIOS déployé sur la plupart des Chromebook de Google, sur lesquels il fonctionne parfaitement et répond au besoin. Des dizaines de millions de Chromebooks ont été livrés avec Coreboot comme BIOS principal !

    Coreboot (né LinuxBIOS) a fonctionné durant ses sept premières années sur serveurs. Son principal usage était dans le domaine du calcul scientifique, mais il n’est malheureusement plus disponible sur serveurs x86 aujourd’hui ! C’est un fort contraste avec les serveurs POWER d’IBM qui s’appuient sur le micrologiciel OPAL librement disponible.

    Je suis donc arrivé avec mes tonnes de questions plus ou moins intelligentes, afin de savoir quoi faire pour essayer de refaire fonctionner Coreboot sur serveurs. Et puis mieux comprendre les complexités auxquelles la communauté de développeurs fait face dans ses rapports avec les fournisseurs de composants qui distribuent les informations techniques au compte‐gouttes.

    En effet, même si Coreboot est un projet libre sur processeur Intel x86, il doit utiliser un ensemble de blobs binaires pour initialiser la machine. Ces blobs incluent notamment les mises à jour des microcodes des processeurs, leurs interconnexions avec les jeux de puces (chipsets) des cartes mères, les cartes graphiques, la reconnaissance mémoire et quelques astuces secrètes des vendeurs de composants. Ces blobs sont disponibles aux gros consommateurs comme Google, ou à tout un chacun, mais sans autorisation de redistribution. Ce qui limite l’intérêt de généraliser leur usage et ne simplifie pas la vie de Coreboot.

    Les serveurs ajoutent en complexité avec la notion de multi‐processeur. Sur puces Intel avec bus QPI notamment, car Intel n’a jamais souhaité fournir de blob binaire pour ce sous‐composant, ce qui rend Coreboot inopérant.

    Alors, avons‐nous une chance d’avoir un code plus ouvert pour nos serveurs préférés ?

    L’espoir vient d’un projet qui s’appelle NERF (Non‐Extensible Reduced Firmware), lancé par une petite équipe d’ingénieurs de Google (dont Ron) qui a eu l’idée folle d’interfacer un noyau Linux avec la fin de la phase d’initialisation PEI des systèmes multi‐processeurs (je sens que je vous ai perdus).

    Depuis quelques années, Intel a introduit les BIOS UEFI (pas une réussite selon moi), qui délimite l’initialisation d’un système en plusieurs étapes :

    • l’étape SEC, qui charge les microcodes des processeurs et les démarrent ;
    • l’étape PEI, qui se charge d’initialiser le système (détection mémoire et initialisation QPI) ;
    • l’étape DXE, qui initialise les bus PCI, exécute différents blobs afin de démarrer le système UEFI. Le contenu des blobs est varié et va des pilotes pour les périphériques, à des piles réseau, à des systèmes de fichiers complexes ou encore à la gestion de systèmes de sécurité SMM.

    Tous ces magnifiques blobs, engendrent de sérieux soucis de sécurité, et peuvent avoir très peu d’intérêt pour la prise en charge des BIOS libre. Il apparaît clairement que les phases SEC et PEI resteront probablement propriétaires pour les prochaines décennies, sauf avec le succès possible de RISC-V munis d’un contrôleur mémoire ouvert, ce qui pourrait amener les vendeurs traditionnels à faire un pas en avant. D’un autre côté, nous n’avons pas trop d’inquiétude quant à la sécurité, et peu d’intérêt à réimplémenter pour le moment les phases SEC et PEI avec du code libre tant celui‐ci serait de bas niveau, dépendant des révisions de composants et utile principalement au surcadencement (overclocking), très peu présents dans le domaine des serveurs.

    Interfacer le noyau Linux juste après la phase PEI nécessite de résoudre quelques défis intéressants ! Le premier, un peu bébête mais super complexe : faire rentrer notre code de BIOS dans une NVRAM ridiculement petite

    La plupart des NVRAM de serveurs font 16 Mio, repartis en deux blocs de 8 Mio chacun, dont un alloué au Management Engine (le machin qui réimplémente IPMI) et le second au code du BIOS système qui inclut les phases SEC, PEI, les blobs DXE et le shell EFI. Or, nous avons besoin d’espace !
    L’équipe de Ron a pour cela développé plusieurs outils (attention ne pas les utiliser sans sauvegardes). L’un d’eux s’appelle ME Cleaner, dont l’optique est de supprimer le code du Management Engine et les trous de sécurité associés. Ils utilisent ensuite leur série de UEFITool pour réaliser une « DXE‐ectomie » dans l’optique de supprimer quelques mébioctet des codes DXE (dont un serveur Web !), afin de faire de la place pour Linux.

    Sur une carte de type MinnowBoard Turbot, les blobs ME représentent 5 Mio avant nettoyage, et 300 kio après, laissant suffisamment de place pour Linux et un initramfs.

    Construire un noyau Linux qui peut rentrer dans un petit espace.

    La stratégie adoptée consiste à supprimer tout ce qui n’est pas nécessaire (même la fonction multi‐utilisateur), afin d’avoir un noyau d’une taille inférieure à 1 Mio. Ce noyau est ensuite étendu au fur et à mesure en fonction des besoins.

    Tester que tout fonctionne…

    … avec une approche pas à pas en démarrant tout d’abord le noyau via le shell EFI en association avec son initramfs présent sur un disque SSD SATA, puis remonter dans la pile au fur et à mesure, jusqu’à démarrer le noyau juste après la phase PEI.

    Supprimer le code standard du BIOS…

    … et ouvrir la porte à la créativité, tout en améliorant drastiquement la sécurité en employant un projet comme u-root, qui est un autre projet complétement fou, qui réimplémente la plupart des fonctions basiques d’un shell en Go, un langage bien plus sécurisé que C contre les erreurs de programmation et capable de compiler à la volée du code source. Une image de u-root au format bzImage fait entre 3 et 5 Mio

    Si vous voulez en savoir plus, voilà une petite vidéo de Ron lors de la conférence Usenix 2015.

    Est‐ce que ça marche sur serveur Open Compute ?

    Avant que je ne rencontre Ron, la réponse était non. Depuis, nous lui avons fourni un peu de matériel et de support, et après quelques semaines de travail acharné, l’équipe a été capable de démarrer un noyau Linux. Il reste quelques problèmes non négligeables, comme initialiser correctement les interruptions, mais nous sommes proches de quelque chose de fonctionnel (pas pour de la prod, hein).

    C’est quoi les prochaines étapes ?

    L’équipe de Ron a un programme d’amorçage (bootstrap) complet fonctionnel basé sur u-root avec un client wget, capable de téléverser un nouveau noyau et de le démarrer via kexec, permettant de s’affranchir du vieux et très lent TFTP. Il nous reste à proposer des menus de configuration du démarrage kexec, améliorer les systèmes de déploiement automatique de la solution, travailler sur la sécurisation du démarrage en utilisant un TPM.

    Un des avantages en utilisant ces méthodes, c’est que l’on arrive à démarrer un serveur de bout en bout en moins de cinq secondes, là où un BIOS AMI de compétition peut mettre environ deux minutes. On s’affranchit aussi au passage de l’exécution des ROM des cartes PCIe qui sont remplacées par de vrais pilotes présents dans le noyau Linux, bien plus efficaces et à jour.

    Le travail de Ron et de son équipe, associé aux serveurs Open Compute, permettra potentiellement de reprendre un contrôle total de son infrastructure. C’était vraiment un élément qui manquait actuellement dans le monde du matériel libre et nous sommes proches de combler ce trou. Il reste énormément de travail et de créativité. L’équipe de Ron est ouverte aux contributions, n’hésitez pas a rejoindre la communauté u-root [dépôt GitHub] et à soumettre vos premiers correctifs.

    Supporter des serveurs avec des micrologiciels libres permet aussi d’améliorer la durée de vie des machines en maintenant ce logiciel critique ; on apporte ainsi des solutions techniques plus pérennes.

    La bonne question est maintenant : « Qui sera le premier à acheter un serveur fonctionnel avec NERF pour démarrer la machine ? »

    P.‐S. : Je tiens à remercier Ron qui a participé a la relecture en version anglaise et j’espère que ma traduction reflète le texte commun sur lequel nous avons travaillé.

    Télécharger ce contenu au format Epub

    Lire les commentaires

    Le Manifeste agile pour l’Éducation

    28 juin, 2017 - 11:00

    Depuis deux ans, le collectif OpenAcadémie se démène pour réformer depuis le terrain les établissements scolaires et la relation à l’usager (élèves et parents) par le numérique, agile et libre. Nous cherchons maintenant à étendre cette action, en nous faisant connaître au‐delà des premiers innovateurs issus de l’intendance, jusqu’aux profs et aux chefs d’établissement.

    Le Manifeste agile pour l’éducation, c’est une tentative de buzz pour que notre propre ministère prenne au sérieux nos propositions. On a finalement choisi OpenAcadémie comme nom pour la démarche, mais on avait pensé aussi à « BougeMammouth »…

    À l’origine d’OpenAcadémie

    Un intendant qui bricole des machins en bases de données. Un autre intendant qui tient un site Web sur le métier. Puis, le ministère qui propose le concours Impulsions pour l’administration innovante nous a décidés à sortir du bois, à recruter. Un peu après, nous sommes tombés sur une interview du secrétaire d’État à la réforme de l’État d’alors, qui nous a donné l’idée de nous rapprocher du SGMAP (Secrétariat général pour la modernisation de l’action publique, chez LinuxFr.org tout le monde connaît Etalab).

    L’état d’esprit : ouvert, libre, agile

    Nous produisons des outils numériques libres, ouverts, développés en communauté, en prise directe avec les utilisateurs. Les logiciels que nous publions sont annoncés sous la bannière de la licence GPL 3.0. Le plus important pour nous, c’est d’être au plus près du terrain et des utilisateurs, qui nous font remonter leur réception dans la vraie vie : des utilisateurs pas doués pour l’informatique, avec du matériel de piètre qualité, des consignes contradictoires, des usages bien ancrés qui confinent à l’illégalité…

    Nous sommes désespérés par le mode de développement logiciel de notre ministère, qui aboutit à des catastrophes industrielles récurrentes. Un cahier des charges de plusieurs centaines de pages est établi, le marché attribué, s’ensuivent des années de développement en mode tour d’ivoire (ah non, ne nous demandez pas un changement, c’est pas dans le cahier des charges) et la livraison en retard d’un machin totalement inadapté. Les logiciels Progré, Gospel, Sconet-GFE, Sirhen, sont autant de preuves, payées au prix fort par le contribuable, que ce modèle est inefficace et voué à l’échec. Or, rien ne change, le logiciel comptable des 8 000 établissements secondaires publics est en cours de réforme suivant toujours le même processus : les intendants du pays sont divisés entre ceux qui espèrent dans les nouvelles fonctionnalités et ceux qui sont déjà convaincus qu’elles ne marcheront pas…

    Pas fun : la technologie que nous employons

    Promis, on a cherché pendant des années un moyen de faire autrement. Mais pour que nos collègues, sans aucune formation au développement, puissent un peu participer à la construction de nos logiciels, nous n’avons pas trouvé autre chose que Microsoft Access. Jeû sais, çaimal. Mais, jusqu’à nouvel ordre, LibreOffice Base est inutilisable et Kexi n’est pas porté sous Windows. Or, nos machines professionnelles sont coincées sous MS Windows et on ne voit pas poindre de changement dans le bon sens dans ce ministère ! On s’efforce de ne pas pousser nos utilisateurs à acheter des licences Access en faisant, quand c’est possible, des applications qui marcheront avec le « lecteur » gratuit Runtime. Chers amis, il n’est pas interdit de lire la suite de cette dépêche…

    Les outils que nous avons déjà produits
    • MobiliSCO : gestion des voyages pédagogiques, notre grand succès, avec 30 % des établissements du pays qui l’ont déjà téléchargé ;
    • GemaSCO : gestion des manuels scolaires ;
    • Bourse.beta : dématérialisation de la demande de bourse en collège ;
    • Cogefi : analyse financière automatisée ;
    • TrombinoSCO : gestion des photos des élèves (trombinoscopes, cartes de lycéen…) ;
    • DossierSCO : dossiers d’inscription à l’établissement pré‐remplis (le logiciel est encore instable, contactez‐nous pour le tester).
    Plein d’idées, pas de moyens pour les réaliser

    Le fait d’avoir obtenu, à l’été 2015, le premier prix national du concours de l’innovation déjà cité n’a rien changé : nous développons pour l’essentiel la nuit, pendant les vacances. Lorsque l’un d’entre nous a réussi à mettre la main sur un stagiaire capable de participer, tout de suite ça s’est vu sur le rythme de développement. Nous manquons cruellement d’un peu de ressources pour faire ce boulot, et on n’arrive pas à se faire entendre, à faire comprendre qu’il y a moyen pour presque rien de faire bouger les lignes dans les usages de milliers de fonctionnaires actuellement mal employés à faire un boulot inefficace et sans intérêt.

    D’où notre tentative de pétition en ligne : le Manifeste agile pour l’éducation a pour but de nous faire remarquer de notre propre ministère qui nous ignore, et de montrer au nouveau secrétariat d’État au numérique que nous n’allons pas en rester là. Alors, si tout cela vous semble en valoir la peine, lisez et signez cette pétition !

    Télécharger ce contenu au format Epub

    Lire les commentaires

    Org-mode 3/5 : des liens et des images dans vos notes

    28 juin, 2017 - 10:56

    Org-mode est un mode de l’éditeur de texte GNU Emacs utilisé pour la prise de notes, la gestion de tâches, la publication de documents, de blogs, les bibliographies, etc., même la synchronisation avec un smartphone ! Oui, oui, oui, les possibilités d’utilisation d’org-mode sont nombreuses et diverses. Tout ça en texte brut.

    Ben Maughan de Pragmatic Emacs a rédigé cinq tutoriels d’introduction à Org-mode sur la prise de notes et leur publication. La suite présente son troisième article (traduit en français avec l’accord de l’auteur).

    NdM : j’ai profondément revu la traduction initiale de ptitjano pour conserver le style rapide, concis et rythmé de l’auteur.

    Cette série d’introduction sur Org-mode se concentre sur les notes en texte simple. Nous avons déjà vu comment structurer vos notes et y ajouter des tableaux.

    L’étape suivante, c’est d’ajouter des liens et des images. Les liens pointent vers des fichiers, des URL ou des emplacements dans le document actuel. Si c’est un lien vers une image, alors Emacs peut l’afficher directement dans le document org. C’est pratique pour améliorer vos notes et ce sera utile lorsque nous les exporterons dans différents formats.

    Comme avant, je suggère d’ajouter les notes ci‐dessous au fichier org en cours.

    N. B. : Ci‐dessous, j’ai formaté les notes comme du texte brut à cause d’Org-mode qui change l’apparence des liens en cachant les [] autour — c’est plus joli dans votre document Org-mode, mais c’est plus difficile pour vous montrer ce qui se passe !

    * Les liens et les images Org mode gère les liens vers les fichiers, vers les URL et les liens qui pointent dans le document. Nous allons utiliser une image de mon site. D'abord, copiez-là dans le répertoire courant. On peut le faire sans quitter Emacs, mais pour l'instant on va taper cette commande dans un terminal : curl http://www.star.bris.ac.uk/bjm/superman_cluster.gif -o superman_cluster.gif Pour mettre un lien vers un fichier, faites C-u C-c C-l et indiquez le nom du fichier. Avec le tab-complètement sélectionnez l'image que nous venons de copier, ensuite on vous demandera une description — vous pouvez faire Entrée pour laisser ça vide. Ça va créer un lien qui ressemble à ça : [[file:superman_cluster.gif]] Dans votre fichier org, vous ne verrez pas les [[ ]] ci-dessus, à la place vous aurez le texte comme un lien cliquable. Comme on a inséré une image, on peut dire à Emacs de l'afficher dans le document avec C-C C-x C-v puis utiliser la même commande pour masquer l'image à nouveau. Vous pouvez aussi cliquer sur le lien, ou faire C-C C-o pour le suivre, ça lancera le navigateur web ou un afficheur d'images, ou bien ça ouvrira un fichier dans Emacs, ça dépend de la cible du lien. Dans org-mode, la structure d'un lien ressemble à ça : #+EXEMPLE_DÉBUT [[adresse du lien][description]] #+EXEMPLE_FIN (J'ai entouré le lien d'un bloc exemple qui empêche org-mode de l'interpréter comme un lien réel, afin d'en montrer la structure — on reviendra plus tard sur ce genre de bloc.) L'adresse du lien c'est l'URL ou le fichier, et la description c'est le texte affiché, nous pouvons donc remplacer notre lien superman par un truc plus propre comme [[file:superman_cluster.gif][ça]]. Les liens vers les pages web c'est facile — tapez l'adresse http dans la partie adresse. C-c C-l le fait en raccourci (vous vous souvenez, avec C-u C-c C-l on a mis un lien vers un fichier). Les liens vers d'autres endroits du fichier org, c'est aussi facile que [[Les liens et les images][ça]]. Comme l'adresse correspond à un titre de ce document, org-mode pointe le lien vers cette partie du fichier. Cliquer dessus emmènera le curseur là-bas. Enfin on peut ajouter un chapeau et un nom à notre image #+CAPTION: Superman et le cluster galactique #+NAME: img.super [[file:superman_cluster.gif]] ça permet de renvoyer plus tard à notre image avec un lien comme [[img.super]]

    Ben Maughan, Org-mode basics III: add links and images to your notes, le 11 septembre 2015.

    Ce 20 juin, Ben Maughan vient d’enrichir Org-mode d’une fonction améliorée pour les liens internes : vous pouvez choisir votre lien dans une liste.

    Télécharger ce contenu au format Epub

    Lire les commentaires

    Revue de presse de l’April pour la semaine 25 de l’année 2017

    27 juin, 2017 - 20:28

    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

    [Silicon] Windows 10 S, un OS un peu trop propriétaire
    Par Jacques Cheminat, le vendredi 23 juin 2017. Extrait :

    « À peine lancé, Windows 10 S se révèle très restrictif au point de rendre impossible l’accueil de logiciels tiers comme les antivirus. »

    Et aussi :

    [Radio Prague] La disparition de la vie privée n’est pas inévitable
    Par Lucie Drechselová, le mardi 20 juin 2017. Extrait :

    « Pour la publicité ciblée comme pour les campagnes électorales, les informations concernant notre activité en ligne sont très prisées sur le marché des données personnelles. Pour beaucoup, la sécurité de l’information et la protection des données sur internet semblent certes être des sujets importants mais souvent trop techniques voire ennuyeux. Mais devons-nous nous résilier à laisser nos données personnelles à la portée de n’importe qui sur la toile? Informaticien français basé à Prague, Jerôme Poisson apporte une réponse: selon lui, la perte de la vie privée n’est pas inévitable. »

    Et aussi :

    [Developpez.com] La NSA rend disponibles via Open Source Software certains des outils qu’elle a développés en interne
    Par Stéphane le calme, le lundi 19 juin 2017. Extrait :

    « La NSA a fourni une liste d’outils qu’elle a développés et qui sont désormais accessibles au public via Open Source Software (OSS) dans le cadre de son TTP (Technology Transfer Program). Pour rappel, c’est dans le cadre de son programme TTP que la NSA transfère la technologie qu’elle a développée en interne à l’industrie, au milieu universitaire et à d’autres organismes de recherche, des transferts qui vont “profiter à l’économie et à la mission de l’Agence”. »

    Et aussi :

    [ZDNet France] _Législatives : Mounir Mahjoubi et Bruno Bonnell élus, Alexandre Zapolsky et Axelle Lemaire battus
    Par Thierry Noisette, le lundi 19 juin 2017. Extrait :

    « L’actuel secrétaire d’État au Numérique est élu, l’ancienne perd, Bruno Bonnell bat l’ex‐ministre Najat Vallaud‐Belkacem et le patron de Linagora échoue dans le Var. »

    Et aussi :

    [Numerama] L’Assemblée nationale compte désormais 26 défenseurs du logiciel libre
    Par Julien Lausson, le lundi 19 juin 2017. Extrait :

    « L’association de promotion et de défense du logiciel libre a fait ses comptes: sur les 497 candidats et candidates en lice pour les législatives qui ont signé le pacte du logiciel libre, seule une toute petite portion a franchi le second tour avec succès. »

    Voir aussi :

    Télécharger ce contenu au format Epub

    Lire les commentaires

    Meilleures contributions LinuxFr.org : les primées de mai 2017

    26 juin, 2017 - 19:17

    Nous continuons sur notre lancée de récompenser ceux qui chaque mois contribuent au site LinuxFr.org (dépêches, commentaires, logos, journaux, correctifs, 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 mai 2017 :

    Abonnement d’un an à GNU/Linux Magazine France (éditions Diamond)

    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

    Première sortie d’Élixir : embarquez, naviguez !

    26 juin, 2017 - 09:35

    Ça fait quelques années que Free-Electrons propose de naviguer dans le code source de notre bien‐aimé noyau. Le vénérable Linux Cross Reference (LXR) ayant un peu de mal quand le vent et les grosses vagues se lèvent, ils ont cherché autre chose : OpenGrok, la dernière version 2.2 de LXR… Une petite plongée dans le code plus tard, Mikael Bouillot, secouant sa crinière, a décidé de coder un outil simple et léger, sans bases de données superflues : Elixir — comme le langage, oui, mais c’est codé en Python.

    LXR a été créé en 1994 pour naviguer aisément dans le code source du noyau Linux. La sortie est en HTML avec tous les liens qu’il faut. Au début, LXR n’utilisait pas de base de données SQL, ce qui avait l’avantage d’être simple et rapide. Free-Electron a choisi d’utiliser la version LXR 0.3.1 (stable et sans SQL) pendant trèèèès longtemps.

    Alors pourquoi créer un nouveau moteur ?

    LXR 0.3.1 c’est un peu vieux et limité… Depuis 1999 le Web a changé, le noyau avec ses arbres et son historique de développement sont beaucoup, beaucoup, beaucoup, beaucoup, beaucoup plus gros, Linus a développé Git, etc., et Free-Electrons voulait étendre son service vers d’autres projets tout en l’améliorant (Web adaptatif (responsive design)). Tout ça devant demeurer simple, rapide et léger. L’arlésienne, quoi !

    Il y a une autre raison : Free-Electrons voulait vraiment beaucoup améliorer son service ! Il s’agissait de fournir les dernières révisions tout en conservant des références non modifiables (immutable), c’est‐à‐dire que quiconque plaçait un lien vers ces jolis petits bouts de code en C serait assuré de le retrouver quelques siècles plus tard (soyons visionnaires).

    Il s’agissait, près de l’herbage
    D’un champ de choux verts et pommés
    Un champ de rêve en vérité
    Qui excitait sa convoitise
    Et qu’un vieux berger protégeait.
    Les bergers sont d’une bêtise !

    (interlude)

    Deux grandes idées :
    1. Comme dans LXR 0.3, fuir comme la peste les moteurs de bases de données relationnelles et rester frugal avec un stockage en listes de paires clefs‐valeurs ;
    2. Utiliser le modèle de données de Git pour éviter d’indexer de multiples versions identiques d’un fichier. Indexer les blobs de Git suffit puisqu’ils sont partagés entre les révisions.

    Et tout ça reste assez simple, deux petits scripts en Python se répartissent le boulot d’indexer et produire les pages à la demande, Ctags fournissant les identifiants.

    L’interlude poétique est extrait d’une fable de Jean‐Pierre Rosnay : La chèvre et le chou.

    Télécharger ce contenu au format Epub

    Lire les commentaires

    Sortie de GCC 7.1

    24 juin, 2017 - 21:33

    La sortie de la nouvelle version majeure du compilateur GCC du projet GNU a été annoncée le 2 mai. Écrit à l’origine par Richard Stallman, le logiciel GCC (GNU Compiler Collection) est le compilateur de référence du monde du logiciel libre. Il accepte des codes sources écrits en C, C++, Objective-C, Fortran, Java, Go et Ada et fonctionne sur une multitude d’architectures.

    La suite de la dépêche vous propose une revue de certaines améliorations et nouvelles fonctionnalités de cette nouvelle version.

    Sommaire Mais que veut dire GCC ?

    En août 1987, GCC signifiait GNU C Compiler (compilateur C de GNU) car il ne prenait en charge que le langage de programmation C. Mais dès décembre 1987, la prise en charge expérimentale du C++ a été intégrée (stabilisée avec GCC 2 publié en 1992). Six autres langages de programmation seront pris en charge progressivement (Objective-C, Objective-C++, Fortran, Java, Ada, et Go).

    Le divergence (fork) EGCS a commencé à avoir du succès. Après une longue période de négociation, les deux projets se sont finalement réunifiés en avril 1999 pour donner un nouveau nom : GNU Compiler Collection, en conservant le même acronyme que le projet original. La première version du nouveau projet fut GCC 2.95.

    Donc, depuis 1999, GCC signifie GNU Compiler Collection et prend en charge neuf langages de programmation (et bien d’autres expérimentalement ou avec des extensions).

    Collection de langages de programmation
    1. C, avec gcc ;
    2. C++, avec g++ ;
    3. Objective-C ;
    4. Objective-C++ ;
    5. Fortran, avec gfortran ;
    6. Java, avec gcj (qui est mort) ;
    7. Ada, avec GNAT ;
    8. Go, avec gccgo ;
    9. OpenMP (c’est un langage qui étend d’autres langages de programmation) ;
    10. Cilk Plus ;
    11. OpenACC ;
    12. Unified Parallel C avec le GCC UPC compiler (expérimental).

    Des logiciels tiers (third parties) permettent la prise en charge d’autres langages :

    1. Pascal, avec gpc ;
    2. Modula (2 et 3) ;
    3. PL/I ;
    4. D, avec gdc ;
    5. VHDL, avec ghdl.
    Schéma de version

    Le projet GCC a modifié son schéma de version en août 2014 pour faire coïncider l’année 2015 à la version GCC 5 et ainsi de suite pour donner : 2016 → GCC 6, puis 2017 → GCC 7. Attention, nous devrions donc avoir GCC 10 en 2020.

    Détail des versions avec le nouveau schéma :

    Branche de développement (2014-04-11) de GCC 4.10 | | GCC 4.10 renommée (2014-08-13) GCC 5.0 | | Branche de développement de GCC 5 | +-------- Branche de livraison | GCC 5.x (2015-04-12) | | | v | GCC 5.1 (2015-04-22) | | | v Branche GCC 5.2 (2015-07-16) de dév. | GCC 6 v | GCC 5.3 (2015-12-04) | | | v | GCC 5.4 (2016-06-03) |\ | \ | `----- Branche de livraison | GCC 6.x (2016-04-15) | | | v | GCC 6.1 (2016-04-27) | | Branche v de dév. GCC 6.2 (2016-08-22) GCC 7 | | v | GCC 6.3 (2016-12-21) |\ | \ | `----- Branche de livraison | GCC 7.1 (2017-05-02) | | v | Branche v de dév. Branche de correction GCC 8 de bogues sur GCC 7

    Nouveautés spécifiques à un ou des langages Ada

    Sur les plates‐formes les plus courantes, les programmes Ada n’ont plus besoin que la pile soit exécutable pour fonctionner correctement.

    BRIG (HSAIL)

    Prise en charge de BRIG 1.0. BRIG est un format binaire pour HSAIL (Heterogeneous System Architecture Intermediate Language).

    Famille C/C++

    Les langages C et C++ partagent les améliorations suivantes :

    • en cas d’erreur (de frappe) sur le nom d’une variable membre, GCC 6 pouvait déjà suggérer un nom correct. GCC 7 va encore plus loin et détectant des noms mal orthographiés de fonctions, macros, types, énumérations, etc. ;
    • le préprocesseur suggère aussi une correction si une directive est mal écrite ;
    • ajout des contrôles de débordement pour les opérations arithmétiques, __builtin_add_overflow_p,__builtin_sub_overflow_p et __builtin_mul_overflow_p ; contrairement à leurs équivalents sans le _p final, ceux‐ci ne demandent pas d’argument pour ranger le résultat de l’opération.
    Améliorations spécifiques au langage C
    • -fopenmp comprend le mot‐clef _Atomic de C11 ;
    • ajouts des types flottants étendu, FloatN et FloatNx ; la disponibilité de ces types dépend de l’architecture utilisée.
    Améliorations spécifiques au langage C++
    • prise en charge expérimentale de C++17 (-std=c++1z) ;
    • l’ordre d’évaluation des expressions peut être activé hors C++17 (-fstrong-eval-order) ou désactivé pour ce dernier (-fno-strong-eval-order) ;
    • implémentation des fonctionnalités C++17 au sein de la libstdc++.
    Fortran

    La version 4.5 de la spécification OpenMP est maintenant partiellement gérée par le compilateur Fortran.

    Go
    • il y a une implémentation complète des paquets utilisateurs de Go 1.8.1 ;
    • par rapport à la chaîne de compilation de Go 1.8.1, le ramasse‐miettes est plus conservateur et moins concurrent ;
    • -fgo-optimize-allocs et -fgo-debug-escape
    Java

    Java (GCJ) n’existe plus (mais le code est toujours disponible via le gestionnaire de versions).

    Diagnostics

    Pour aider à la correction de bogues, GCC 7 apporte ces directives intéressantes :

    • -fdiagnostics-parseable-fixit : les suggestions de correction sont diffusées sous un format plus lisible et capable d’être mieux digéré par les EDI ;
    • fdiagnostics-generate-patch : produit un fichier correctif dans le format unifié (patch -u) à la fin du diagnostic.
    Délestage

    Depuis la version 5, deux implémentations sont proposées pour délester, complètement ou partiellement, l’exécution de code par un processeur externe (c.‐à‐d. un ou plusieurs processeurs graphiques) : OpenACC et OpenMP.

    Cette version améliore la prise en charge des spécifications OpenACC 2.0A et autorise le délestage de régions openMP par les processeurs graphiques NVIDIA (PTX).

    Ces deux interfaces sont accessibles via la bibliothèque libgomp.

    Divers Télécharger ce contenu au format Epub

    Lire les commentaires