Linux (fr)

  • Swift sous GNU/Linux - Introduction (Dépêches LinuxFR)

    Swift est le nouveau langage de programmation d’Apple. Il a été rendu libre et open-source, sous licence Apache 2.0, le 3 décembre 2015. Nous allons voir à travers cet article comment l’installer et l’utiliser sur GNU/Linux. Vous n’avez pas besoin d’avoir de connaissance avancée de GNU/Linux, ni de machine avec GNU/Linux installée pour suivre ce tutoriel.

    Swift

    Sommaire

    Installation de Swift sur GNU/Linux

    Si vous avez déjà Ubuntu 14.04 LTS ou Ubuntu 15.10, en machine physique ou virtuelle, vous pouvez simplement suivre les instructions sur le site swift.org pour télécharger et installer Swift pour Linux. Vous pouvez alors vous rendre directement à la section suivante.

    La suite vous décrit les étapes pour installer simplement une machine virtuelle Ubuntu dotée du nouveau langage Swift.

    Installation de VirtualBox

    VirtualBox est un logiciel libre vous permettant de configurer et faire tourner des machines virtuelles. Si ce n’est déjà fait, installez-le en vous rendant à la page de téléchargement du site.

    Installation de Vagrant

    Vagrant est un logiciel en ligne de commande qui permet d’installer et configurer des machines virtuelles à l’aide de scripts. Rendez-vous à la page de téléchargement du site, téléchargez et lancez l’installeur du système d’exploitation de votre machine hôte.

    À l’aide du script suivant, vous allez pouvoir télécharger et configurer votre machine virtuelle en une ligne de commande !

    Créez un dossier vagrant-swift, puis créez dans ce dossier, un fichier nommé Vagrantfile contenant le code suivant :

    Vagrant.configure(2) do |config|
      config.vm.box = "ubuntu/trusty64"
      config.vm.provision "shell", inline: <<-SHELL
        sudo apt-get --assume-yes install clang
        curl -O https://swift.org/builds/ubuntu1404/swift-2.2-SNAPSHOT-2015-12-01-b/swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04.tar.gz
        tar zxf swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04.tar.gz
        echo "export PATH=/home/vagrant/swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04/usr/bin:\"${PATH}\"" >> .profile
        echo "Swift has successfully installed on Linux"
      SHELL
    end

    Pour les utilisateurs Windows, il vous faudra un terminal qui permet d’exécuter des commandes Unix. Je vous recommande Git Bash de la suite Git for Windows. Durant l’installation, vous pouvez laisser toutes les options de configuration par défaut. Une fois installée, vous devez lancer Git Bash.

    Ouvrez un terminal si ce n’est déjà fait (Git Bash si vous êtes sous Windows). Placez-vous dans le répertoire vagrant-swift et lancez la commande suivante :

    $ vagrant up

    Allez boire une bière le temps que Vagrant procède aux étapes suivantes :

    Téléchargement d’Ubuntu 14.04 LTS
    Lancement de la machine virtuelle
    Installation du compilateur clang
    Téléchargement et décompression de Swift
    Configuration de la variable PATH de l’utilisateur

    Vous aurez peut-être des messages affichés en rouge, vous pouvez les ignorer. Si tout s’est déroulé correctement, le dernier message indique :

    ==> default: Swift has successfully installed on Linux
    La machine virtuelle est prête, connectez-vous en ssh en lançant cette commande :

    $ vagrant ssh

    La connexion établie, vous obtenez un prompt de ligne de commande :

    vagrant@vagrant-ubuntu-trusty-64~$

    Vérifiez que Swift est bien installé en tapant :

    vagrant@vagrant-ubuntu-trusty-64:~$ swift --version
    Swift version 2.2-dev (LLVM 46be9ff861, Clang 4deb154edc, Swift 778f82939c)  
    Target: x86_64-unknown-linux-gnu

    Premier programme

    Live

    Les développeurs iOS ou OS X le savent déjà grâce au playground d’Xcode, Swift est un langage pouvant être exécuté en live grâce au REPL (Read-Eval-Print-Loop).
    Lancez la commande swift, un prompt apparaît, entrez alors votre première ligne de code Swift sur Linux !

    vagrant@vagrant-ubuntu-trusty-64:~$ swift
    Welcome to Swift version 2.2-dev (LLVM 46be9ff861, Clang 4deb154edc, Swift 778f82939c). Type :help for assistance.
    1> print("Hello, Swift!")
    Hello, Swift!
    2>

    Pour quitter votre session Swift REPL, entrez la commande :q.

    Compiler un programme

    Pour compiler un programme écrit en Swift, créez un fichier source, par exemple de la manière suivante :

    $ cat > helloworld.swift

    Puis rentrez cette unique ligne de code :

    print("Hello World !")

    Appuyez une fois sur Entrée suivi de CTRL-D pour créer le fichier. Listez le répertoire courant pour vous assurer de la présence du fichier fraîchement créé en tapant la commande ls. Compilez maintenant votre programme en tapant :

    $ swiftc helloworld.swift

    Si vous listez le répertoire courant, vous verrez qu’un nouveau fichier exécutable nommé helloworld a été créé. Votre programme est prêt à être lancé, tapez :

    $ ./helloworld

    Vous devriez voir en sortie :

    Hello World !

    Ce qu’Apple a rendu open source

    Seulement une partie de la technologie est disponible en open source pour le moment. Les composants sont :

    • Compilateur Swift, sources et exécutables, débogueur, REPL. C’est le coeur du langage lui-même. Apple a rendu open les sources du programme swiftc, le même compilateur utilisé pour compiler les applications iOS et OS X.
    • Bibliothèque standard Swift. Presque la même bibliothèque standard utilisée depuis la sortie de Swift, elle comprend la définition des collections, protocoles et autres fondamentaux. Si par curiosité, vous voulez voir comment est définie la classe (plus précisément la structure) String, rendez-vous sur le github ici.
    • Bibliothèques Swift core. Elles font peau neuve aux bibliothèques existantes d’Apple écrites en Objective-C. Elles fournissent des fonctionnalités et des outils de haut niveau tels que ceux pour la communication web, l’interaction avec le système de fichiers, les calculs de date et heure.
    • Swift Package Manager. C’est le maître de cérémonie de l’assemblage de chaque brique qui forme une application. Il va télécharger les dépendances, les compiler et les lier entre-elles pour créer des bibilothèques ou des exécutables.
    • Mais encore… Si vous parcourez la page Github d’Apple, vous trouverez d’autres composants tels qu’une encapsulation de libdispatch (Grand Central Dispatch), des informations sur Swift 3.0, ou même un parseur du langage Markdown…

    Ce qui n’est pas (encore) disponible

    Il manque à l’appel la plupart des frameworks qui rendent les applications iOS et OS X aussi belles. Pour n’en citer que quelques-uns : AppKit, UIKit, Core Graphics, Core Animation, AVFoundation…

    Vous ne trouverez pas non plus l’environnement de développement intégré Xcode.

    Mais ce qu’Apple a rendu open source est plutôt significatif. En effet, le fait que les bibliothèques Swift Core ne reposent plus sur l’environnement d’exécution Objective-C montre qu’Apple est en train de créer les fondements de Swift pour, à long terme, remplacer Objective-C. De plus, le fait que Swift soit cross-platform suggère qu’Apple espère voir les développeurs l’utiliser pour le développement d’applications Linux entre autres. Si ce n’est pour des applications GUI, au moins pour des applications serveurs.

    Swift Package Manager

    Voyons en pratique l’utilisation du package manager sur un exemple simple, un petit jeu de « pierre, feuille, ciseaux ». Créez un dossier helloswift puis un dossier sources à l’intérieur du premier en exécutant les commandes suivantes :

    $ mkdir helloswift  
    $ cd helloswift  
    $ mkdir sources  
    $ cd sources

    Créez ensuite un fichier nommé main.swift, (le nom main est important pour la suite), dans le répertoire sources en exécutant :

    $ cat > main.swift
    

    Copiez le programme suivant :

    import Foundation
    import Glibc
    
    let player = ["pierre", "feuille", "ciseaux"]
    
    srandom(UInt32(NSDate().timeIntervalSince1970)) 
    
    for count in 1...3 {
        print(count)
        sleep(1)
    }
    
    print(player[random() % player.count]);

    Tapez Entrée puis CTRL-D.

    Vous pouvez d’ores et déjà exécuter votre programme avec la commande :

    $ swift main.swift
      Génial ! Il faut que j’en parle aux copains !
    Arf… il n’auront pas la commande swift…
    

    C’est ici que le Swift Package Manager entre en jeu ! Grâce à lui, vous allez pouvoir distribuer un exécutable de ce formidable programme. Créez un fichier Package.swift dans le dossier parent (helloswift) :

    $ cd ..
    $ cat > Package.swift

    Copiez ceci dedans puis tapez Entrée et enfin CTRL-D :

    import PackageDescription
    
    let package = Package(
        name: "Chifoumi"
    )

    Lancez la commande de build :

    $ swift build

    Swift détecte automatiquement le point d’entrée du programme car nous avons nommé notre fichier main.swift. Si vous renommez ce fichier, vous aurez des erreurs de compilation. En revanche le changement de nom du dossier sources n’affecte pas la compilation mais l’exécutable créé portera le nom du dossier et non le nom donné dans le fichier Package.swift. Si la compilation réussit, le package manager crée un dossier .build contenant un dossier debug dans lequel se trouve l’exécutable Chifoumi. Vous pouvez alors le distribuer et quiconque ayant une machine Linux pourra l’exécuter en tapant la commande suivante dans le répertoire où se trouve l’exécutable :

    $ cd .build/debug/
    $ ./Chifoumi

    Le Swift package manager possède évidemment beaucoup de fonctionnalités que nous n’avons pas explorées. Un guide d’utilisation plus avancée fera peut-être l’objet d’un nouvel article, qui sait ?

    Stay tuned !

    Références / Sources

    Lire les commentaires

  • Application web de cartographie applicative (Journaux LinuxFR)
    Bonjour,

    Dans le cadre de mon travail, mon service a en charge l'installation et le maintien en condition opérationnel 400 applications différentes (environnement de recette et de production, d'origine pour 99% de développement extérieur, basées sur des progiciels ou étant spécifique). Elles sont réparties sur quasiment un millier de serveurs. Nous nous sommes vite heurtés sur plusieurs problèmes que surement certains d'entre vous connaissent.

    Notamment, le double point de vue que nous devons avoir pour gérer un tel parc : savoir sur quels serveurs tournent une application donnée (point de vue "application") et savoir quelles applications sont hébergées sur un serveur (point de vue "serveur"). Les premiers outils étaient de simples tableaux nécessitant une double mise à jour et donc peu fiable. Chez nous, cela s'appelle la cartographie applicative.

    Une autre difficulté est de pouvoir suivre les demandes d'installations qu'on nous demande de faire. Nous appellons ce point le suivi des "Demandes de Changements Applicatifs". Vu la hausse de notre activité, le suivi par mail a vite montré ses limites.

    Au vu des ces difficultés et n'ayant pas trouvé l'application idéale, j'ai commencé à développer une application web (php/mysql/ajax) pour répondre, dans un premier temps, au suivi des changements applicatifs et à la cartographie dans un deuxième temps.

    Chez nous, elle vient en complément des applications GLPI et OCS :
    - OCS : pour la description technique des serveurs
    - GLPI : pour la répartition géographique des serveurs
    - Mon appli pour le lien avec les applications

    Des interfaces ont été développées pour maintenir à jour les informations partagés entre ces applications.

    Les applications sont décrites en terme de briques de bases (SGBD, serveurs web, serveur d'applications, url d'accès) et de façon très souple. On cartographie aussi bien du SAP, des applications web (java, php), qu'un simple hébergement de pages html statiques.

    La partie gestion des demandes est constituée d'un "Front Office" permettant aux demandeurs de saisir les demandes (dates, contenu des livraisons) et de les suivre. Ce front office est une version allégé de l'application. Les notifications des changements se sont par mails.

    Cette application est maintenant utilisée par une vingtaine de personnes quotidiennement depuis 2 ans et elle occupe un rôle central dans notre activité. On se demande parfois comme on ferrait si on ne l'avait pas.

    Je continue toujours son développement. Sont en prévision la gestion des "demandes de travaux" (dump de bases de données, demandes de logs, lancement de traitements, ...), étendre la cartographie aux traitements de nuits... Donc, plus le projet grossi, plus je me dis que le projet pourrait intéresser d'autres personnes.

    Donc, avant de me lancer dans l'aventure de son ouverture (sachant qu'elle a été conçue en s'adaptant au plus près à notre organisation), j'écris pour tater le terrain. Est-ce que, potentiellement, ce type d'application intéresserait du monde ?

    N'ayant pas l'aval de mon employeur sur la libération du code source, je ne peux pas donner trop de détails pour le moment, mais je n'ai pas rencontrer de refus sur le principe.
  • Falkon 3 le nouveau navigateur pour KDE (Dépêches LinuxFR)

    Vous souvenez‐vous de Qupzilla, petit projet commencé par le tout jeune David Rosca pour apprendre Qt, puis devenu un excellent navigateur WebKit ? En juillet 2017, pendant la réunion annuelle du projet KDE, l’Akademy, David Faure a proposé de remplacer Konqueror par Qupzilla.
    Après quelques mois d’incubation, le bébé sort des éprouvettes : Falkon 3.01 est disponible depuis le 8 mai 2018. C’est un navigateur moderne, dont les onglets tournent dans des processus séparés, en utilisant QtWebEngine, lui‐même basé sur Chromium pour le rendu.
    Logo du navigateur Falkon
    Il n’y a pas de grosses différences avec la dernière version de Qupzilla 2.2.6, c’est essentiellement une transposition vers le système de construction de KDE. Il faut bien commencer.

    Les utilisateurs de Konqueror seront en terrain familier pour la partie Web et le menu de configuration, en revanche la navigation de fichiers n’est pas encore intégrée. Il faut bien commencer (bis).

    Falkon protège bien votre vie privée (gestion des Cookies, de JavaScript, de HTML 5, Do Not Track), vous propose un greffon Flash (Pepper Flash), plusieurs moteurs de recherche (Duck Duck Go par défaut), un gestionnaire de sessions, des onglets avec indicateurs, un traducteur de pages Web, un validateur de code, des thèmes, une page « Speed Dial » facile à gérer, retrouve le contenu du formulaire quand on fait « précédent » — je reprends ma respiration, regardez les images :

    Les indicateurs (cliquables) sur les onglets :
    Onglets avec indicateurs
    Le (très pratique) gestionnaire de sessions :
    Gestionnaire de sessions dans Falkon
    Le (sympathique) menu déroulant « clic droit » :
    Le menu contextuel de Falkon

    Et comme il est jeune et crashe un peu, Falkon recharge automatiquement tous les onglets ouverts. À ce stade, vous le constatez sans doute, c’est dans l’esprit de KDE : un mélange de simplicité et de « super‐pouvoirs » à portée de configuration.

    Quelques extensions disponibles :

    • AdBlock, (San Ku Kaï c’est la bataille) contre les pubs ;
    • KWallet Passwords, un portefeuille pour les gérer tous ;
    • Vertical Tabs, les onglets bien dégagés sur les oreilles ;
    • AutoScroll, pour les claustros qui craignent les ascenseurs ;
    • Flash Cookie Manager, protège plus que plus la vie privée ;
    • GreaseMonkey, soyez le maîîîître du navigateur (scripts dispos sur http://openuserjs.org/) ;
    • ImageFinder, qui recherche par l’image, par l’image trouvera ;
    • Mouse Gesture, pour les souriceaux maniaques ;
    • PIM, pour jouer dans les formulaires ;
    • StatusBar Icons, oh que c’est zouli ces petites friandises là en bas !
    • Tab Manager, « Onglets ! Au rapport ! »

    Les WebExtensions qui sont déjà gérées par Chrome/Chromium, Firefox, Edge et Opera ont encore un long chemin à parcourir.

    L’extension ImageFinder en menu déroulant :
    Recherche par l’image sur Falkon
    L’extension Vertical Tabs en mode hiérarchique :
    Onglets verticaux dans Falkon

    D’ores et déjà, Falkon est un navigateur à mon goût : avec toutes les extensions, plusieurs onglets et trois fenêtres ouvertes, il tourne comme un charme sans charger le système ; je n’ai pas de problème sur les sites Web, ou alors tellement mineurs que je fais avec.

    Falkon est disponible pour GNU/Linux dans vos distributions et aussi en AppImage et Flatpak (via le dépôt KDE), sous Windows (à partir de Win 7) et macOS (à venir).

    Commentaires : voir le flux atom ouvrir dans le navigateur

  • Un rachat, un summit et un BIOS qui s'ouvre de plus en plus grâce à linux (Journaux LinuxFR)

    Me revoilà après plusieurs mois de silence. Il faut dire que depuis la fin 2017, mon agenda s'est retrouvé complètement chamboulé. La société que j'ai créée avec Isabelle (ma moitié comme on dit), a été rachetée par une société américaine, un de nos partenaires de longue date. Nous avons créée Splitted-Desktop Systems (SDS) il y a 11 ans avec pour objectif de concevoir des ordinateurs silencieux respectueux de l'environnement en France. On a beaucoup travaillé (vraiment beaucoup), on a beaucoup galéré (vendre des ordinateurs français à des français c'est complexe (mais je tiens a remercier les membres de linuxfr qui ont été nos clients durant ces dernières années !), et le dernier tweet d'oles me laisse d'ailleurs dubitatif (https://twitter.com/olesovhcom/status/1007519400734359552), on est dans un mode hôpital qui se moque un peu de la ch… . Bon quoiqu'il en soit nos technos frenchies ont et intéressent des américains, on a donc décidé de répondre positivement à l'offre et on s'est pris un Tsunami sur la tête, mais voilà c'est fait ! Annonce rachat

    Certains diront qu'on se vend à l'axe du mal, j'aurai tendance à dire qu'on peut y voir pleins de choses positives. La première c'est un des premiers rachats significatif dans le domaine de l'Open Hardware pour les serveurs. On est racheté par un de nos partenaires de longue date qui a valorisé à un niveau trois fois supérieure notre société par rapport aux meilleurs propositions d'investisseurs français, on pérénise nos emplois et on embauche, on va accélérer sur des tonnes de sujets dont linuxboot, FreeCAD et l'impact de l'open hardware sur les modèles d'économie circulaire ce qui est en soit juste genial !

    Ce qui m'ammène à parler du futur summit Open Compute en Europe. Il se tiendra à Amsterdam (ok c'est pas la France, mais c'est pas loin), et j'y animerai une session complète sur linuxboot durant laquelle on présentera des machines qui fonctionnent sous cet environnement, on aura des sessions de hacking et on discutera de la futur roadmap du projet. Pour ceux qui ne suivent pas ce projet, l'objectif de linuxboot est de remplacer UEFI par un kernel linux dans l'optique de mieux maitriser les phases de démarrage des serveurs, simplifier leur provisioning et surtout de les maintenir en condition opérationnelle le plus longtemps possible grace à l'ouverture du code ! Ca fonctionne, c'est un projet qu'on a créée avec Google, Facebook et quelques autres hackers de haut vol. Si vous êtes impliqués dans le déploiement de serveurs et un peu curieux vous ne pouvez pas louper cet événement ainsi que l'osfc organisé par 9elements (osfc).

    A bientôt, et j'espere vous croiser au summit ou en Allemagne !

    vejmarie

    Commentaires : voir le flux atom ouvrir dans le navigateur

  • Dr. Geo 18.06 (Dépêches LinuxFR)

    GNU Dr. Geo est un logiciel de géométrie interactive euclidienne du plan, pour une utilisation à l'école secondaire et primaire. Il permet d'organiser des activités pédagogiques dans l'enseignement de la géométrie, voire d'autres domaines liés des mathématiques.
    Intégré à un environnement dynamique de programmation Smalltalk, il propose également une approche de la géométrie dynamique par la programmation, soit par l'utilisation de script(s) intégré(s) à une figure, soit par une description purement programmatique d'une construction géométrique. En outre, Dr. Geo est toujours modifiable depuis lui-même, fonctionnalité héritée de son environnement de développement.

    Dr. Geo 18.06

    La version 18.06 fait suite à la version 17.07 sortie en juillet 2017. Une grande partie de l'effort fut de porter le code de la version 3 à la version 7 de l'environnement Smalltalk Pharo avec lequel est développé Dr. Geo. Outre les corrections de bugs inhérentes à ce portage, quelques fonctionnalités nouvelles ont fait leur apparition.

    Nouvelles fonctionalités

    Dans Dr. Geo, un script est défini par une classe Pharo. L'utilisateur insère alors une instance du script dans la figure géométrique ; il lui associe si nécessaire d'autres objets géométriques de la figure en paramètres. Un script effectue un traitement ad-hoc, calculs ou modifications sur d'autres objets de la figure tels que programmés dans les méthodes du script. Une fois défini, le script est facile à utiliser.

    L'édition de script se fait maintenant à l'aide d'un outil d'édition de code dédié, et non plus par l'intermédiaire du navigateur de code de Pharo, qui est pour le moins impressionnant.

    À noter que l'ajout d'attribut au script nécessite toujours l'utilisation du navigateur de code de Pharo. Ce besoin est nécessaire uniquement lorsque le script a un état dont il doit se souvenir tout au long du cycle de vie de la figure.
    Editeur de script

    Le manuel utilisateur a une section dédiée au script.

    Inspecteur sur code de figures programmées

    Une figure programmée est l'autre forme d'utilisation de la programmation dans la géométrie dynamique. Dans cette approche la figure géométrique est entièrement définie par un code Smalltalk et l'utilisation de l'API dédiée.

    Il est dorénavant plus aisé de gérer ses fichiers de figures programmées. Le nouvel inspecteur de Pharo — outre l'inspection d'attributs d'instance de classe — propose aussi de voir, d'exécuter, d'éditer et de créer les scripts de figures programmées.
    Inspecteur sur scripts de figures programmées

    Zoom positionnel

    Pour zoomer dans une figure l'utilisateur dispose du widget de molette orange en haut à droite de chaque figure ou de la molette de la souris. Le zoom par la souris est maintenant positionnel, focalisé sur la position du curseur souris ; celui par le widget reste, lui, centré au milieu de la zone visible de la figure.

    Détection de polygone sans surface

    Lorsqu'un polygone est sans surface (vide), Dr. Geo ne détectera que ses lignes, et non plus sa surface intérieure puisqu'elle n'existe pas.
    Polygone sans/avec surface

    Tests unitaires basés sur figures programmées

    Le petit corpus de figures programmées distribué avec Dr. Geo est également utilisé pour définir une série supplémentaire de tests unitaires.

    Partage réseau

    Dans le cadre d'une activité pédagogique en salle informatique, distribuer aux élèves des fichiers de figures est pratique. Dr. Geo propose maintenant une fonctionnalité de partage en réseau local, indépendante des services du réseau local (NFS, Samba, Windows, etc.). La marche à suivre est la suivante :

    1. L'enseignant sauve les documents à partager dans son dossier DrGeo.app/MyShares : MyShares
    2. L'enseignant active le partage réseau local depuis le navigateur de préférences de DrGeo (menu Système, Préférences) : Activation du partage
    3. L'élève, depuis l'outil habituel d'ouverture de figures, parcourt les figures partagées (bouton 'Partage enseignant') : Parcourir les figures partagées

    Cette fonctionnalité peut s'utiliser de façon croisée avec Linux, Mac et Windows.

    Thèmes graphiques

    Le navigateur de préférences (menu Système, Préférences) donne accès à deux thèmes graphiques, hérités de Pharo :

    • Thème sombre, par défaut, à privilégier lorsque Dr. Geo est utilisé de façon autonome sur un seul poste.
      Thème sombre

    • Thème clair, à utiliser en vidéo projection, par exemple, car le thème sombre manque de contraste.
      Thème clair

    Option plein écran

    Depuis le menu système, l'utilisateur peut basculer en affichage plein écran ; le système hôte est alors complètement masqué. Pratique pour que les élèves se concentrent sur leur activité de géométrie dynamique.

    Les autres modifications de la version 18.06.

    Commentaires : voir le flux atom ouvrir dans le navigateur

  • Microcontrôleur de DEL basé sur ESP8266 (Dépêches LinuxFR)

    ANAVI Light Controller est une nouvelle carte matérielle libre pour contrôler un ruban de DEL (LED strip RGB). Ce projet est libre et conçu avec KiCAD, et disponible à l’achat à partir de 25 € jusqu’au 27 juin 2018.
    plan du Anavi Light Controller sur KiCAD
    La carte peut être utilisée de façon autonome avec le logiciel embarqué de démo en se connectant sur une page Web (MQTT d’Eclipse Paho). Mais passer par Internet via un broker MQTT public n’est peut‐être pas idéal pour tous, donc une autre solution est tout aussi envisageable via une passerelle locale (et optionnellement accessible à distance).

    Naturellement, ce microcontrôleur (MCU) ESP8266 peut être aussi reprogrammé, c’est une alternative intéressante aux populaires Arduino car un bloc Wi‐Fi (pas libre ?) est intégré au MCU.

    Pour ma part, j’ai eu la chance de tester le produit, ça fait le job comme on dit ! Mais je vous invite à lire la revue en français sur le blog Framboise314.

    Pour utiliser une passerelle locale, il faut préalablement installer Mozilla IoT Gateway sur Raspberry Pi et reprogrammer le MCU avec mon implémentation de RGBLamp qui utilise l’API WebThings de Mozilla se connectant ensuite via mDNS, HTTP, REST (voir vidéo)…

    webthing-esp8266-webapp-20180602rzr

    Pour ceux qui ne veulent pas faire un pas hors de leur système d’exploitation préféré, considérez le précédent produit de Léon pour Raspberry Pi.

    Finalement, si vous utilisez Mozilla IoT, les retours sont bienvenus.

    Commentaires : voir le flux atom ouvrir dans le navigateur

  • Compilation de VSCode sous Centos 6 (Journaux LinuxFR)

    Il y a quelques mois, le camarade freem< nous avait fait part de ses déception concernant VSCode parce qu'il ne trouvait pas matière à troller de manière satisfaisante.

    J'ai voulu me faire mon propre avis et l'essayer par moi même. Malheureusement, ma machine pro est une Centos 6 et la libc disponible beaucoup trop vielle. Impossible de l'essayer et donc de partager avec vous mes impressions pertinentes et de kalitay :(. Quelques moules m'ont gentiment expliqué que je n'avais qu'à me sortir les doigts du fondement et le compiler moi même, que si je voulais vraiment, je pouvais.

    Plusieurs mois plus tard, j'ai enfin trouvé le temps et la motivation d'essayer. Et à ma grande surprise, ce fut plutôt facile.

    # Installation d'une version décente de GCC, python et git depuis les dépots 
    # Softawre Collections
    sudo yum install centos-release-scl
    sudo yum install devtoolset-7 python27 rh-git29
    
    # Installation de NodeJS et Yarn
    curl --silent --location https://rpm.nodesource.com/setup_6.x | sudo bash -
    curl --silent --location https://dl.yarnpkg.com/rpm/yarn.repo | sudo tee /etc/yum.repos.d/yarn.repo
    sudo yum install nodejs yarm
    
    # Activation de l'environnement de compilation
    scl enable python27 devtoolset-7 rh-git29 bash
    
    # Récupération des sources de VSCode
    git clone https://github.com/Microsoft/vscode.git
    cd vscode
    
    # Augmentation de la limite du nombre de fichiers ouverts à 166384
    # (il peut être nécessaire de modifier /etc/security/limits.conf pour atteindre
    # cette valeur)
    ulimit -n 166384
    
    # Récupération des dépendances
    # (On défini la variable CXX parce que sinon un des makefile utilise 
    # /usr/bin/g++ qui ne supporte pas C++11 )
    CXX=$(which g++) yarn
    
    # Construction du paquet
    yarn run gulp vscode-linux-x64-min
    
    # "Instalation"
    mv ../VSCode-linux-x64 ~/opt/vscode

    Et voilà ! À moi les joies des d'un éditeur moderne !

    $ ~/opt/vscode/bin/code-oss
    /home/killruana/opt/vscode/bin/../code-oss: error while loading shared libraries: libgtk-3.so.0: cannot open shared object file: No such file or directory

    Lourd est le parpaing de la réalité sur la tartelette aux fraises de nos illusions. :'(

    Rendez-vous dans quelques mois pour la suite de mes aventures avec vscode.

    Commentaires : voir le flux atom ouvrir dans le navigateur

  • 1 mois avec UBPORTS sur un téléphone LG Nexus 5 (Journaux LinuxFR)

    Ubports est un projet qui continue le développement de Ubuntu Touch après l'arrêt de celui-ci par Canonical. Le projet est actif, avec un financement sur Patreon.
    Ubports est à ma connaissance la seule distribution Linux (autre qu’Android et dérivés comme Lineage OS ) utilisable actuellement sur téléphones/tablettes (peu de modèles, voir plus loin).
    ( Sailfish OS est en pause, il y a aussi un nouveau projet de Linux sur Samsung (en fait pas vraiment pareil , car Linux ne sera utilisable que quand le téléphone sera relié à un écran/clavier), ou encore le futur Purism )

    Donc, ce journal est un retour sur l’utilisation d’Ubports sur un téléphone Nexus 5. C'est un peu la suite de ce journal de gnumdk datant de 2016: 1 an sous Ubuntu Phone .

    Choix du téléphone:

    Peu de modèles compatibles, et plutôt anciens (voir ici ) .
    Le Nexus 5 est le modèle le mieux supporté . Il n’est pas trop dépassé (cpu 2 ghz, 2 go ram, full hd, 32 go de stockage interne). J’en ai acheté un sur Ebay pour moins de 100 € (prendre un d821 pour l’Europe) .

    Installation:

    J’ai utilisé MDT (magic device tool): voir ici .
    Sur le téléphone connecté en usb, il faudra activer le mode développeur, rebooter en mode bootloader (Touches Power + Vol- appuyées au redémarrage) , accepter le déblocage du bootloader.
    L’installation dure longtemps : certaines étapes durent 10 mn sans signe d’activité.
    Si il n’y aucune activité pendant plus longtemps , forcer un reboot pour reprendre l’installation .
    Quand l’interface Ubuntu apparait, il faut faire la dernière mise à jour OTA2 depuis les paramètres, puis rebooter un dernière fois.

    Utilisation

    Interface utilisateur :

    Au début, on est assez gêné par la disparition des 3 touches en bas de l’écran . Il faut s’habituer à utiliser la barre de tache à gauche de l’écran et la touche “retour” du navigateur. Finalement, la barre de tache est très pratique , elle permet en plus de quitter les applis , ce qui manque sur Android.
    Après quelques plantages pendant les premiers jours, le système est stable , pas de reboot depuis 7 jours .

    Téléphone et sms:

    Cela marche bien , le son est bon , les notifications d’appel fonctionnent..

    Photo :

    Fonctionne

    Wifi et 4g :

    Fonctionne bien , pas de déconnections wifi

    Batterie:

    C’est moyen: la décharge est assez rapide quand on fait fonctionner le navigateur (suffisant pour plusieurs heures quand même) . Couper le wifi et la 4g pour la veille téléphone permet de dépasser largement 24h sans recharge (d’après la courbe de décharge, ça pourrait tenir 48h ).

    pas de problème , de rares blocages , c’est Chromium à ce qu’il semble. Les versions “mobiles” des sites passent bien (quand elles existent) : je les utilise pour un webmail, ma banque, chess.com , Google drive etc …. Cela corrige un peu le manque d’applis disponibles .

    Applis sur Openstore :

    Elles proviennent de l’ancien store de Ubuntu Touch, qui est encore accessible quelques temps : les 2 stores sont donc accessibles depuis le téléphone.
    Certaines applis ne sont pas (encore?) dans Openstore comme le “Clementine remote” .
    J’utilise une appli Flas pour le stream radio , une appli mail Dekko, un navigateur GPS Unav (pas assez testé , semble fonctionner en mode “en ligne”, possibilité de charger des cartes depuis Openstreetmap pour le mode “hors ligne” mais pas de navigation dans ce cas )

    Pour Deezer, et Spotify , pas de site mobile. Pour Spotify , une appli “Cutespotify” mais il faut un compte premium.
    C'est corrigé par une appli “cloudmusic” qui utilise un fournisseur chinois et accède à 10 millions de morceaux (pas que chinois) sans pub et légalement (?) , (voir cette question ) .
    Le journal 1 an sous Ubuntu Phone traite plus longuement des applis disponibles.

    Conclusion:

    UBports marche assez bien pour mon usage quotidien et en plus, c’est vraiment amusant à utiliser. J'espère avoir donné envie à certains de l'essayer…

    Lire les commentaires

  • Mise aux poings sur systemd (Dépêches LinuxFR)

    systemd est un gestionnaire du système et de services (aussi appelé « PID 1 », car c’est le premier processus à être lancé) pour Linux, compatible avec SysV et les scripts d’init LSB. systemd a des capacités de parallélisation énergiques. Il utilise les sockets et l’activation par D-Bus pour démarrer les services, permettant le démarrage à la demande des démons. Il surveille et commande les processus avec les groupes de contrôle (cgroups) Linux. Il prend en charge la construction d’instantanés et la restauration de l’état du système. Il maintient les points de montage et d’auto-montage, et implémente une logique de contrôle transactionnelle élaborée fondée sur les dépendances entre services.

    systemd ne fait pas partie du projet freedesktop.org, bien qu’hébergé sur le site. Il est codé en langage C et publié sous licence GNU GPL 2.1+. Il a été lancé par Lennart Poettering, auteur de PulseAudio et d'Avahi entre autres, et est maintenant activement développé par plusieurs dizaines de développeurs.

    La dernière dépêche concernant systemd a suscité de nombreuses réactions et certaines d'entre elles montraient une méconnaissance de ce logiciel : la dépêche se contentait, pour la majeure partie il est vrai, de traduire les notes de versions.

    Je vais donc faire un point sur systemd, histoire d’en finir une bonne fois pour toutes avec les discussions sans fin sur systemd (l’espoir fait vivre).

    Sommaire

    Ce qui suit est en grande partie une traduction d’un article Les 30 plus grands mythes à propos de systemd paru en janvier 2013 sur le site de Lennart Poettering.

    Donc à partir de maintenant et jusqu’à la fin, c’est Lennart Poettering qui (indirectement) parle !


    Depuis la première proposition d’inclusion de systemd au sein des distributions, on en a fréquemment parlé sur de nombreux forums, listes de diffusion et conférences. Dans ces discussions, on peut souvent entendre certains mythes à propos de systemd, qui sont répétés encore et encore, sans que cette répétition ne les rende vrais pour autant. Prenons le temps d’en briser quelques-uns :

    systemd est monolithique

    systemd est constitué de plus de 70 binaires (NdT : 72 sur ma machine !) clairement séparés. D’une part, systemd a été conçu pour être sécurisé : chaque binaire effectue une tâche très spécifique avec des privilèges minimaux — en utilisant les capacités (capabilities) du noyau par exemple — pour réduire la surface d’attaque et l’impact de failles de sécurité. Cela rend également systemd plus robuste et plus facile à faire évoluer et à déboguer. D’autre part, cette séparation est essentielle pour que systemd puisse lancer ces binaires en parallèle. Beaucoup d'entre eux sont même si bien séparés qu’ils peuvent aussi être utiles en dehors de systemd (systemd-detect-virt, systemd-tmpfiles ou systemd-udevd, par exemple).

    Un ensemble de plusieurs dizaines de binaires peut difficilement être qualifié de monolithique. À la différence de ce qui se pratiquait auparavant, les composants sont dans une seule archive, et ils sont tous maintenus en amont dans un seul dépôt avec un cycle de publication unifié — ce qui est sans doute bénéfique au bon fonctionnement de l’ensemble.

    systemd a été conçu pour la vitesse

    Oui, systemd est rapide (on peut obtenir un espace utilisateur presque complet en à peu près 900 ms !), mais c’est principalement un effet secondaire d’avoir fait les choses correctement. En fait, nous n’avons jamais essayé d’optimiser chaque parcelle de systemd ; au contraire, nous avons fréquemment choisi en toute connaissance de cause un code légèrement plus lent en faveur de la lisibilité du code. Cela ne veut pas dire que la vitesse ne nous intéresse pas, mais réduire systemd à sa vitesse est une idée fausse, car ce n’est pas du tout dans nos priorités.

    La vitesse de systemd ne sert à rien pour les serveurs !

    C’est complètement faux. Beaucoup d’administrateurs désirent réduire les temps d’arrêt des fenêtres de maintenance. Pour les configurations à haute disponibilité, c’est sympathique d’avoir une machine indisponible qui redevient très vite disponible (le besoin utilisateur étant « toujours disponible », même s’ils oublient les interventions techniques (montée de version de logiciel, d’OS…), vu qu’ils ont une approche « nos utilisateurs » pour lesquels une nouvelle version ne correspond qu’à des ajouts, pas des régressions…). Pour les configurations dans les nuages avec un nombre important de machines virtuelles ou de conteneurs, le cout d’un démarrage lent est multiplié par le nombre d’instances. Passer plusieurs minutes de temps CPU et d’entrées/sorties sur des démarrages très lents de milliers de machines virtuelles ou de conteneurs réduit la densité de votre système de façon importante, cela vous coute même plus d’énergie. Un démarrage lent peut vous couter beaucoup d’argent, alors qu’un démarrage rapide permet d’implémenter une logique d’activation de conteneurs par socket pour augmenter la densité de votre système dans les nuages.

    Bien entendu, pour la plupart des configurations de serveur, le temps de démarrage n’est pas intéressant, mais systemd est censé couvrir le plus de cas possibles. Et oui, je suis au courant que c’est souvent le micrologiciel du serveur qui prend le plus de temps au démarrage, et que le système d’exploitation démarre vite en comparaison, mais tous les serveurs n’ont pas un aussi mauvais micrologiciel, et certainement pas les machines virtuelles ni les conteneurs, qui sont un type de machine virtuelle également.

    Note : nous essayons de faire notre petite part pour rendre les micrologiciels meilleurs. En mettant les performances de démarrage du micrologiciel en évidence dans la sortie de systemd, nous espérons que la honte poussera les auteurs de micrologiciels à nettoyer leur travail.

    systemd est incompatible avec les scripts shell

    C’est complètement bidon. Nous ne les utilisons pas pour le processus de démarrage parce que nous pensons qu’ils ne sont pas le meilleur outil pour cette tâche spécifique, mais cela ne signifie pas que systemd n’est pas compatible avec eux. Vous pouvez facilement lancer des scripts shell en tant que service systemd, systemd n’a strictement rien à faire de ce qui est à l’intérieur de votre exécutable. De plus, nous utilisons énormément les scripts shell pour installer, construire et tester systemd. Et vous pouvez continuer à utiliser vos propres scripts très tôt dans le démarrage, les utiliser comme des services normaux, les lancer à l’extinction de la machine, il n’y a quasiment aucune limite.

    systemd est compliqué

    C’est aussi un non-sens total. Une plateforme systemd est en réalité beaucoup plus simple que les Linux traditionnels, car elle unifie le système d’objets et leurs dépendances en unités systemd. Le langage des fichiers de configuration est très simple et on se débarrasse des fichiers de configuration redondants. Nous fournissons des outils uniformes pour la plupart des tâches de configuration du système. Le système est beaucoup moins aggloméré que les Linux traditionnels. Nous avons également une documentation plutôt complète (tout est présent sur la page d’accueil) sur à peu près tous les détails de systemd, et cela ne couvre pas seulement les interfaces pour utilisateur et administrateur, mais également les API pour les développeurs.

    systemd nécessite bien sûr un apprentissage. Comme toute chose. Cependant, nous aimons croire que c’est vraiment plus simple de comprendre systemd qu’un démarrage fondé sur des scripts shell pour la plupart des gens. Surpris de ces paroles ? Eh bien, il s’avère que le shell n’est pas un langage sympathique à apprendre, sa syntaxe est obscure et complexe. Les fichiers unités de systemd sont beaucoup plus simples à comprendre, ils ne nous exposent pas à un langage de programmation, mais sont simples et déclaratifs par nature. Cela dit, si vous avez de l’expérience en shell, en effet, adopter systemd vous demandera un petit peu d’apprentissage.

    Afin de rendre l’apprentissage facile, nous avons fait notre maximum pour fournir une compatibilité avec les solutions précédentes. De plus, sur de nombreuses distributions, vous remarquerez que certains des outils traditionnels vous diront — en faisant ce que vous leur aviez demandé — comment vous pourriez le faire avec les nouveaux outils à la place, possiblement d’une façon plus agréable.

    Bref, systemd ne peut probablement pas être plus simple qu’il ne l’est déjà pour la tâche qu’il remplit, et nous avons travaillé dur pour qu’il soit simple à apprendre. Alors oui, si vous connaissez sysvinit alors adopter systemd va vous demander un peu d’apprentissage ; mais franchement, si vous maitrisez sysvinit, alors systemd devrait être facile pour vous.

    systemd n’est pas modulaire

    Tout faux. À la compilation, il y a beaucoup d’options de configuration pour choisir ce que vous voulez compiler ou non. Et nous documentons comment sélectionner encore plus en détail ce dont vous avez besoin, en allant plus loin que les options de configuration.

    Cette modularité n’est pas totalement différente de celle du noyau Linux, où vous pouvez sélectionner beaucoup de fonctionnalités individuellement à la compilation. Si le noyau est assez modulaire pour vous, alors systemd l’est probablement.

    systemd est seulement pour les ordinateurs de bureau

    Ce n’est certainement pas vrai. Avec systemd, nous essayons à peu près de couvrir la même portée que Linux. Alors, que nous tenons compte des usages bureautiques, nous tenons aussi compte des usages serveur, ainsi que des usages embarqués. Vous pouvez parier que Red Hat ne voudrait pas en faire une pièce centrale de RHEL 7 si ce n’était pas la meilleure option pour gérer les services des serveurs.

    Des personnes de différentes entreprises travaillent sur systemd. Les fabricants de voitures l’intègrent dans leurs voitures, Red Hat l’utilise pour ses systèmes d’exploitation pour serveurs, et GNOME utilise nombre de ses interfaces afin d’améliorer le bureau. Vous le trouvez dans les jouets, les télescopes et dans les éoliennes.

    La plupart des fonctionnalités sur lesquelles j’ai travaillé récemment, relèvent du domaine des serveurs, comme le support des conteneurs, le management des ressources ou des fonctionnalités de sécurité. Nous couvrons plutôt bien les systèmes bureautiques pour le moment, et il y a de nombreuses entreprises faisant du développement sur systemd pour l’embarqué, certaines offrent même des services de consultance pour lui.

    systemd est un résultat du syndrome NIH (NdT : Not Invented Here, « Pas inventé ici »)

    Ce n’est pas vrai. Avant que nous commencions à travailler sur systemd, nous poussions l’adoption à grande échelle d’Upstart (et Fedora/RHEL l’utilisent également depuis un moment). Cependant, nous sommes finalement arrivés à la conclusion que le cœur de sa conception présentait des défauts (au moins à nos yeux : plus fondamentalement, il laisse la gestion des dépendances à l’administrateur/au développeur, au lieu de résoudre ce problème difficile dans le code) et, si quelque chose ne va pas dans le cœur, il vaut mieux le remplacer que de le corriger. Ça n’est pas la seule raison cependant, d’autres choses ont joué, comme le bordel autour du CLA. NIH n’était cependant pas une des raisons…

    Note : et puis, devinez quel projet inclut une bibliothèque « libnih » — Upstart ou systemd ? (indice : ça n’est pas systemd !)

    systemd est un projet freedesktop.org

    Ma foi, c’est vrai que systemd est hébergé sur fdo, mais freedesktop.org n’offre pas grand-chose de plus qu’un dépôt pour le code et la documentation. À peu près tous les développeurs peuvent demander de l’espace et déposer leurs affaires ici (à condition d’avoir un vague rapport avec l’infrastructure des systèmes libres). Il n’y a pas de cabale, pas de processus de standardisation, pas de vérification de projet, rien. C’est juste un hébergement sympa, gratuit et solide pour mettre un dépôt. De ce point de vue, c’est un peu comme sourceforge, github, kernel.org, mais de nature non commerciale et sans demandes excessives et donc, un bon endroit où mettre notre projet.

    Donc oui, nous avons choisi fdo pour l’hébergement, mais l’hypothèse implicite de ce mythe, qu’il existe un groupe de gens qui se rencontrent et qui décident du futur des systèmes libres, est entièrement fausse.

    systemd n’est pas UNIX

    Il y a certainement du vrai en cela. Les sources de systemd ne contiennent pas une seule ligne de code héritée de l’UNIX originel. En revanche, notre inspiration nous vient d’UNIX et c’est pourquoi il y a beaucoup d’UNIX en systemd. Par exemple, l’idée d’UNIX du « tout est fichier » trouve son jumeau dans systemd où tous les services sont exposés au lancement dans un système de fichiers du noyau, le cgroupfs. Ensuite, une des fonctionnalités originelles d’UNIX était celle des multi-terminaux (multi-seat), basée sur la prise en charge des consoles (terminaux d'ordinateurs). Les consoles en mode texte ne sont pas vraiment la manière dont vous interagissez avec votre ordinateur de nos jours. Avec systemd, nous avons apporté le retour de la gestion des multi-terminaux, mais cette fois avec la gestion complète des composants modernes, des cartes graphiques aux souris, systèmes audio, webcams et bien plus, et tout cela complètement automatique, branchements à chaud et sans configuration. En effet, le design de systemd en tant que suite d’outils intégrés dont chacun a ses buts propres, voilà la philosophie du cœur d’UNIX. Ensuite, la façon dont notre projet est géré (c'est-à-dire maintenir la majeure partie du cœur de l’OS dans un unique dépôt git) est plus proche du modèle BSD (qui est un vrai UNIX, pas comme Linux) dans la façon de faire (où la plus grande partie du cœur de l’OS est conservé dans un seul répertoire CVS/SVN) que de la façon de faire de Linux.

    Enfin, UNIX est quelque chose de différent pour chacun. Pour nous, les mainteneurs de systemd, c’est quelque chose dont nous nous inspirons. Pour d’autres, c’est une religion, et tout comme les autres religions du monde, il y a différentes façons de lire ou d’interpréter. Certains définissent UNIX comme un héritage de certains bouts de codes spécifiques, d’autres le voient juste comme un ensemble d’idées, d’autres comme un ensemble de commandes, et d’autres encore comme une définition de comportements. Bien sûr, il est impossible de faire en sorte que toutes ces personnes soient heureuses.

    Finalement, la question de savoir si quelque chose est UNIX ou non importe vraiment peu. Être techniquement excellent n’est pas exclusif à UNIX. Pour nous, UNIX est une influence majeure (zut, la plus grosse), mais nous avons aussi d’autres influences. Ainsi, dans certains domaines systemd sera vraiment UNIX et dans d’autres un peu moins.

    systemd est complexe

    Il y a un fond de vérité à cela. Les ordinateurs modernes sont des choses complexes et le système qui tourne dessus doit donc être complexe aussi. Toutefois, systemd n’est pas plus complexe que les implémentations précédentes des mêmes composants. Au contraire, il est plus simple et réduit les redondances (voir plus haut). De plus, construire un système simple basé sur systemd impliquera moins de paquets qu’un système Linux traditionnel. Avoir moins de paquets facilite la construction du système et permet de se débarrasser des interdépendances et des comportements divergents de chaque composant impliqué.

    systemd est une usine à gaz

    Hé bien, il y a probablement plusieurs définitions de « usine à gaz ». Mais dans la plupart des définitions, systemd est probablement l’opposé d’une usine à gaz. Vu que les composants systemd partagent une base de code commune, ils ont tendance à partager plus de code pour les fonctions générales. Voici un exemple : dans une configuration Linux traditionnelle, sysvinit, start-stop-daemon, inetd, cron, dbus implémentent tous une façon de lancer des processus avec des options de configuration variées dans un environnement que l’on espère propre. Dans systemd, les fonctions pour tout ceci, que ce soit le parsing (NdT : analyse syntaxique si vous y tenez vraiment) de la configuration ou le lancement lui-même, sont partagées. Cela se traduit par moins de code, moins de place pour faire des erreurs, moins de mémoire occupée et moins de pression sur le cache, et donc c’est une très bonne chose. Et en plus, vous gagnez une tonne de nouvelles fonctionnalités grâce à ça.

    Comme mentionné plus haut, systemd est aussi plutôt modulaire. Vous pouvez choisir à la compilation les composants dont vous avez besoin et ceux dont vous pouvez vous passer. De sorte que les gens peuvent choisir à quel point systemd est une « usine à gaz ».

    Quand vous compilez systemd, il ne demande que 3 dépendances : glibc, libcap et dbus. C’est tout. Il peut utiliser beaucoup plus de dépendances, mais elles sont toutes entièrement optionnelles.

    Donc oui, sous tous les angles, ce n’est vraiment pas une usine à gaz.

    systemd seulement pour Linux, pas sympa pour les BSD

    Complètement faux. Les gens de chez BSD ne sont pas vraiment intéressés par systemd. Si systemd était portable, cela n’aurait rien changé, ils ne voudraient pas l’adopter quand même. Et la même chose est vraie pour les autres Unix dans le monde. Solaris a SMF, BSD a son propre système rc, et ils l’ont toujours maintenu séparément de Linux. Le système d’initialisation est très proche du cœur du système d’exploitation. Et ces autres systèmes d’exploitation se définissent eux-mêmes, entre autres choses, par le cœur de leur espace utilisateur. L’hypothèse qu’ils aient adopté notre cœur d’espace utilisateur si nous l’avions juste rendu portable est sans aucun fondement.

    systemd seulement pour Linux empêche son adoption comme système d’initialisation par défaut sur Debian

    NdT : Debian est déjà passée à systemd, mais on traduit aussi cette partie pour le plaisir. :p

    Debian prend en charge des noyaux non-Linux dans leur distribution. systemd ne fonctionnera pas sur ceux-ci. Est-ce que c’est cependant un problème, et cela doit-il gêner l’adoption de systemd par défaut ? Pas vraiment. Les gens qui ont porté Debian sur ces noyaux sont prêts à investir du temps dans un portage qui demande beaucoup de travail, ils ont mis en place des systèmes de tests et de compilation, patché et compilé de nombreux paquets pour atteindre ce but. La maintenance à la fois d’une unité systemd et d’un script d’initialisation classique pour les services empaquetés est une charge de travail négligeable comparé à cela, en particulier parce que le plus souvent ces scripts existent déjà.

    systemd pourrait être porté sur d’autres noyaux si ces mainteneurs le voulaient

    C’est tout simplement faux. Faire un portage de systemd sur d’autres noyaux n’est pas faisable. Nous utilisons trop d’interfaces spécifiques à Linux. Pour certaines, on peut trouver des remplacements sur les autres noyaux, pour d’autres nous pourrions les désactiver, mais pour la plupart, ce n’est vraiment pas possible. Voici une petite liste non exhaustive: cgroups, fanotify, umount2(), /proc/self/mountinfo (incluant les notifications), /dev/swaps (de même), udev, netlink, la structure de /sys, /proc/$PID/comm, /proc/$PID/cmdline, /proc/$PID/loginuid, /proc/$PID/stat, /proc/$PID/session, /proc/$PID/exe, /proc/$PID/fd, tmpfs, devtmpfs, capacités, espaces de nommages en tout genre, divers prctl()s, de nombreux ioctls, l’appel système mount() et sa sémantique, SELinux, audit, inotify, statfs, O_DIRECTORY, O_NOATIME, /proc/$PID/root, waitid(), SCM_CREDENTIALS, SCM_RIGHTS, mkostemp(), /dev/input, et ainsi de suite.

    Si vous regardez cette liste et prenez les quelques éléments auxquels vous pouvez trouver un équivalent évident dans d’autres noyaux, alors réfléchissez à nouveau, et regardez ceux que vous n’avez pas considérés et la complexité nécessaire pour les remplacer.

    systemd n’a pas de raison de ne pas être portable

    Ça n’a aucun sens ! Nous utilisons des fonctions spécifiques à Linux parce que nous en avons besoin pour implémenter ce que nous voulons. Linux a beaucoup de fonctionnalités qu’UNIX/POSIX n’a pas, et nous voulons que les utilisateurs puissent en tirer parti. Ces fonctions sont incroyablement utiles, mais seulement si elles sont offertes de manière conviviale à l’utilisateur et c’est ce que nous voulons faire avec systemd.

    systemd utilise des fichiers de configuration binaire

    Je n’ai aucune idée d’où est sorti ce mythe fou, mais ça n’est absolument pas vrai. systemd est configuré quasi exclusivement par de simples fichiers textes. Vous pouvez également modifier quelques options avec la ligne de commande du noyau ou par des variables d’environnement. Il n’y a rien de binaire dans sa configuration (même pas de XML). Seulement des fichiers en texte brut, simples, et faciles à lire.

    systemd est un cauchemar de fonctionnalités

    Eh bien, systemd couvre certainement plus de terrain que par le passé. Ce n’est plus uniquement un système d’initialisation, mais le bloc de base de l’espace utilisateur à partir duquel construire un système d’exploitation ; mais nous faisons attention de garder optionnelles la plupart des fonctionnalités. Vous pouvez en désactiver beaucoup lors de la compilation, et encore plus lors de l’exécution. Ainsi pouvez-vous choisir librement combien de fonctionnalités injecter.

    systemd vous force à faire quelque chose

    systemd n’est pas la mafia. C’est un logiciel libre, vous pouvez en faire ce que vous voulez, ce qui inclut ne pas l’utiliser. C’est plutôt l’opposé de « forcer ».

    systemd rend impossible l’utilisation de syslog

    C’est faux, nous avons fait attention lors de l’introduction du journal à ce que les informations soient transmises au serveur syslog. En fait, s’il y a bien une chose qui a changé, c’est surtout le fait que syslog reçoit maintenant plus d’informations, car nous nous occupons du début du démarrage système ainsi que des flux STDOUT/STDERR de tous les services du système.

    systemd est incompatible

    Nous faisons de notre mieux pour garantir la meilleure compatibilité possible avec sysvinit. En fait, la grande majorité des scripts d’initialisation fonctionne telle quelle sous systemd, sans modifications. Toutefois, il y a effectivement quelques incompatibilités, mais nous essayons de les documenter et d’expliquer comment y réagir. En fin de compte, tout système qui n’est pas systemd aura une certaine dose d’incompatibilité avec lui vu qu’il n’aura pas exactement la même structure d’exécution.

    Notre but est que les différences entre les multiples distributions restent à un niveau minimum. Cela implique que les fichiers unité fonctionnent généralement bien sur une distribution différente de celle où ils ont été conçus, ce qui est un énorme progrès sur les scripts classiques d’initialisation qui sont très difficiles à écrire d’une façon portable à d’autres distributions Linux, compte tenu des nombreuses incompatibilités entre elles.

    systemd n’est pas scriptable, à cause de son utilisation de D-Bus

    Ce n’est pas vrai. Presque chaque interface D-BUS que fournit systemd est aussi accessible via un outil en ligne de commande, par exemple dans systemctl, loginctl, timedatectl, hostnamectl, localectl et autres. Vous pouvez aisément appeler ces outils depuis des scripts shell, ils donnent accès à pratiquement toute l’API depuis la ligne de commande avec des commandes faciles d’emploi.

    Cela dit, D-Bus a aussi une interface (NdT : bindings) pour presque tous les langages de script de ce monde. Même depuis le shell on peut invoquer des méthodes D-Bus quelconques avec dbus-send ou gdbus. Finalement, cela facilite son utilisation dans des scripts grâce à la bonne gestion de D-Bus par les différents langages de script.

    systemd requiert l’utilisation d’obscurs outils de configuration au lieu d’éditer des fichiers textes directement

    Ce n’est pas vrai du tout. Nous proposons des outils de configuration, et leur utilisation vous fournit quelques fonctionnalités complémentaires (par exemple, la complétion en ligne de commande de tous les paramètres !), mais ils ne sont en rien nécessaires. On peut toujours modifier les fichiers en question directement si on le souhaite, et c’est totalement accepté. Bien sûr que quelquefois on a besoin de recharger explicitement la configuration d’un démon après l’avoir modifiée, mais ceci est vrai de la plupart des services UNIX.

    systemd est instable et bogué

    Selon nos données, certainement pas. Nous analysons minutieusement le système de suivi de bogues (NdT : bugtracker) de Fedora (et d’autres) depuis longtemps. Le nombre de bogues est très faible pour un tel composant central du système d’exploitation, surtout si on en retranche les nombreuses propositions d’améliorations (NdT : RFE) que nous enregistrons dans ce projet. Nous sommes plutôt bons pour maintenir systemd hors de la liste des bugs bloquant la distribution. Notre cycle de développement est plutôt rapide avec principalement des modifications incrémentales pour conserver un haut niveau de qualité et de stabilité.

    systemd n’est pas déboguable

    Faux. Certains sous-entendent que le shell était un bon débogueur. Hé bien pas vraiment. Dans systemd nous vous fournissons de véritables capacités de débogage. Par exemple, le débogage interactif, une traçabilité détaillée, la possibilité de masquer n’importe quel composant pendant le démarrage et plus encore. Nous fournissons aussi la documentation associée.

    Il est sans aucun doute parfaitement débogable, nous en avons nous-mêmes besoin pour notre propre développement. Cependant nous reconnaissons une chose : il utilise des outils de débogage différents, dont nous pensons qu'ils sont plus appropriés à l’objectif.

    systemd fait des changements pour le plaisir de changer

    Largement mensonger. Nous avons à peu près uniquement des raisons techniques aux différents changements apportés, et nous les expliquons dans les multiples documentations, pages de wiki, articles de blogues et annonces dans les listes de diffusion. Nous faisons un réel effort pour éviter les changements incompatibles, et si nous y sommes contraints, nous essayons d’en documenter en détail la cause et la modalité. Et s’il vous reste des questions, n’hésitez pas à nous les poser !

    systemd est un projet uniquement dirigé par Red Hat, une propriété privée de quelques développeurs je-sais-tout, qui l’utilisent pour servir leur vision du monde

    C’est faux. Actuellement (NdT : 2013-01-16), il y a 16 développeurs avec le droit de commit sur le dépôt git. Dans ces 16 développeurs, seulement 6 sont employés par Red Hat (NdT : le compte a changé depuis). Les 10 autres sont des gens d’ArchLinux, de Debian, de Mageia, d’Intel, de Pantheon et même de Canonical, ainsi qu’un certain nombre de gens de la communauté. Et ils font souvent de grosses modifications et des changements majeurs. Ensuite, il y a aussi les 374 particuliers avec des patchs dans notre dépôt. Ils viennent aussi d’horizons et d’entreprises variés et plusieurs ont bien plus qu’un seul patch dans le dépôt. Les discussions sur le futur de systemd sont faites de façon ouverte sur notre canal IRC (#systemd sur freenode, vous êtes les bienvenus), sur notre liste de discussion et lors de nos hackfests publiques (comme la prochaine qui aura lieu à Brno, où vous êtes cordialement invité). Nous assistons régulièrement à diverses conférences pour avoir des retours, pour expliquer ce que nous faisons et pour quelle raison, à un degré que peu de projets font. Nous gardons à jour les blogs, nous engageons la discussion sur les réseaux sociaux (nous avons du contenu assez intéressant sur Google+, et notre communauté Google+ est relativement vivante aussi), et nous tentons ardemment d’expliquer pourquoi et comment on fait les choses et on écoute les retours, afin de trouver où sont les soucis (par exemple, avec ces retours, nous avons écrit cette liste de mythes courants sur systemd…).

    La plupart des contributeurs à systemd partagent probablement une idée grossière de ce à quoi un bon système d’exploitation devrait ressembler, ainsi que le désir de la voir se concrétiser. Cependant, par la nature Open Source même du projet et son implantation dans la communauté, systemd est simplement ce que les gens veulent qu’il soit et si ça n’est pas ce qu’ils veulent, ils peuvent influencer la direction du projet avec des patchs et du code, et si ça n’est pas possible, il y a alors de nombreuses autres options à épuiser. systemd n’est jamais fermé.

    Un but de systemd est d’unifier un peu le paysage dispersé de Linux. Nous essayons de nous débarrasser de beaucoup des différences inutiles entre distributions dans différents domaines du cœur de l’OS. Dans ce cadre, nous adoptons parfois une méthode spécifique à une distribution et l’utilisons par défaut pour systemd dans le but de pousser gentiment tout le monde vers le même ensemble de configurations de base. Ce n’est cependant pas une obligation, les distributions peuvent continuer de le faire à leur manière. Cependant, si elles finissent par adopter le standard, leur travail devient plus simple et elles peuvent gagner une fonctionnalité ou deux. Actuellement, la plupart des standards que nous avons adoptés venaient de Debian plutôt que de Fedora/RHEL. Par exemple, les systèmes qui utilisent systemd stockent généralement leur nom d’hôte dans /etc/hostname, ce qui était auparavant spécifique à Debian et maintenant utilisé sur plusieurs distributions.

    Une chose que je vous accorde cependant est que nous pouvons certaines fois avoir l’air de monsieur-je-sais-tout. Nous essayons d’être préparés à chaque fois que nous ouvrons notre bouche, dans le but de soutenir nos affirmations. Cela peut nous faire passer pour des monsieur-je-sais-tout.

    De façon générale, effectivement, quelques-uns des plus influents contributeurs de systemd travaillent pour Red Hat. Cependant ils sont une minorité et systemd est une communauté saine et ouverte avec différents intérêts, différentes expériences, simplement unifiée par quelques idées grossières de la direction à prendre, une communauté où le code et sa conception comptent, mais certainement pas l’affiliation à une entreprise.

    systemd ne gère pas l’utilisation d’un /usr séparé du répertoire racine

    Absurde. Depuis ses débuts systemd gère l’option --with-rootprefix= pour son script configure, ce qui vous permet de dire à systemd de bien séparer les choses nécessaires au début du démarrage de celles nécessaires plus tard. Toute cette logique est complètement présente et nous la gardons à jour dans le système de compilation de systemd.

    Bien sûr, nous ne pensons toujours pas qu’amorcer sans /usr disponible est une bonne idée, mais nous le prenons parfaitement en charge dans notre système de compilation. Cela ne corrigera pas les problèmes inhérents du procédé que vous rencontrerez partout, mais vous ne pouvez pas accuser de cela systemd, car dans systemd nous le gérons très bien.

    systemd ne permet pas de remplacer ses composants

    Faux, vous pouvez désactiver et remplacer à peu près n’importe quel bout de systemd, à de très rares exceptions près. Et ces exceptions (comme journald) en général vous permettent d’utiliser une alternative côte à côte tout en coopérant avec elle.

    L’utilisation de D-Bus dans systemd au lieu de sockets le rend opaque

    Cette affirmation est déjà contradictoire en elle-même : D-Bus utilise les sockets comme transport. Donc, chaque fois que D-Bus est utilisé pour envoyer quelque chose, une socket est utilisée. D-Bus est pour majeure partie une sérialisation standardisée de message à envoyer à travers ces sockets. Cela le rend plus transparent, car ce format de sérialisation est bien documenté, compris, et il y a de nombreux outils de traçage et des liaisons de langage (language bindings). C’est complètement à l’opposé des habituels protocoles maison que les divers démons Unix classiques utilisent pour communiquer localement.


    Hum, ai-je écrit que je voulais briser juste « quelques » mythes ? Peut-être qu’il y en avait plus que quelques-uns… Quoi qu’il en soit, j’espère que j’ai réussi à éliminer certaines idées fausses. Merci de votre temps.

    Lire les commentaires

  • Migrer Windows 10 d'un disque BIOS/MBR, vers un SSD en mode UEFI/GPT avec des logiciels libres (Journaux LinuxFR)

    Sommaire

    Introduction

    Ce tutoriel vous guide pas à pas pour migrer votre installation de
    Windows qui est actuellement sur un disque dur de votre PC vers un
    nouveau disque, en l'occurrence un SSD. A vrai dire, vous pouvez aussi
    bien migrer vers un autre HDD.

    La spécificité de ce tutoriel est qu'elle utilise les outils fournis par
    Microsoft avec Windows ainsi que des logiciels libres (Clonezilla
    principalement, mais si quelque chose devait mal tourner vous pouvez avoir
    besoin d'utiliser fdisk, gdisk ou testdisk pour ne citer qu'eux). Quand
    j'ai voulu faire cette migration je n'ai pas trouvé de tutoriel
    expliquant de bout en bout comment faire cette migration juste avec les
    outils de Microsoft et des logiciels libres.

    Typiquement, vous pouvez avoir envie/besoin de faire cela car vous avez
    acheté un nouveau disque pour remplacer l'ancien (par exemple car
    l'ancien montre des signes de faiblesse, ou vous voulez améliorer la
    réactivité de votre système).

    En plus de la migration du système d'exploitation, ce tutoriel vous
    explique comment passer d'un démarrage en mode BIOS/MBR à un démarrage
    en mode UEFI/GPT.

    Succinctement la démarche est la suivante, d'abord installer le nouveau
    disque dans le PC, et initialiser la table de partition selon les normes
    Microsoft. Puis cloner/dupliquer la partition contenant le système
    d'exploitation à l'aide de Clonezilla. Ensuite et avant de redémarrer
    dans le clone de Windows sur le SSD, faire quelques modifications dans
    le registre pour que la lettre de lecteur C: pointe vers la bonne
    partition et éventuellement modifier le mode SATA en AHCI si vous le
    modifiez aussi dans le UEFI/BIOS. Après cela, on va préparer la
    partition système EFI/ESP pour que le PC puisse démarrer dessus et qu'il
    démarre sur le Windows du SSD. Finalement, une fois dans le Windows du
    SSD, on va réactiver l'"environnement de récupération de Windows".

    Mise en garde : Faites une sauvegarde de vos données avant toute
    opération. Personne n'est à l'abri d'une mauvaise manipulation ou d'une
    erreur.

    Prérequis

    Compétences

    Niveau de difficulté : Difficile.

    Vous devez être à l'aise au niveau de l'utilisation de la ligne de
    commande dans Windows, mais aussi assez à l'aise pour gérer les
    partitions de votre disque. Savoir modifier le paramétrage de votre
    Firmware UEFI/BIOS et aussi nécessaire. Ce tutoriel guide pas à pas pour
    la majorité des opérations. Certaines n'ont pas été détaillées par souci
    de simplicité et d'efficacité.

    Matériel

    Le PC où vous voulez installer le SSD. Il faut qu'il soit en état de
    marche. De plus il doit avoir un firmware UEFI. S'il n'a que un BIOS
    standard, sans UEFI, ce tutoriel n'est pas adapté.

    Clé(s) USB ou plusieurs CD/DVD sur lequel vous aurez mis
    Clonezilla, System rescue
    CD
    et un environnement de démarrage
    Windows PE, ou Windows RE, ou le DVD/Disque d'installation de Windows.

    Le disque SSD (testé avec Samsung SSD 860 EVO 250GB). Il doit avoir une
    taille suffisante pour contenir votre partition de Windows. Dans tous
    les cas, la taille de la partition qui contiendra Windows sur le SSD
    doit être au moins égale à la taille de la partition Windows du HDD que
    vous voulez cloner. Au besoin, pour remplir ce critère, réduisez la
    taille de votre partition Windows avec le gestionnaire de disque de
    Windows par exemple (ou un autre outil de gestion de partition, comme
    gparted, sur le System Rescue CD). Cherchez sur internet si vous ne
    savez pas comment faire.

    Logiciel

    Windows 10 installé (en version 64 bits) (testé avec Win10 v1709)

    Windows 10 PE ou support d'installation de Windows 10 (clé USB ou DVD) -
    En Version 64 bits (testé avec un support d'installation de Win10 v1804)

    System rescue CD (version 5.2.2 par
    exemple)

    Clonezilla installé sur une clé ou un CD.
    Bien vérifier avant que votre système arrive à démarrer dessus. (Testé
    avec Clonezilla 2.5.5-38)

    Nomenclature

    SSD : désigne le nouveau SSD

    HDD : désigne votre disque actuel, sur lequel est installé Windows

    WinPE : un environnement de démarrage Windows PE, ou Windows RE, ou le
    DVD/Disque d'installation de Windows. Il doit être sur un support
    amovible (USB, CD ou DVD)

    S: La lettre de lecteur affectée à la partition Système EFI qui sera sur
    le nouveau SSD (parfois appelée ESP, EFI_System_Partition ou encore
    SYSTEM, ou EFI)

    N: Le clone de Windows, sur le SSD

    O: Le Windows cloné, sur le HDD

    C: La partition dans laquelle est installée Windows, lorsqu'on est dans
    Windows (que ce soit le windows cloné, ou le clone)

    Les commandes doivent être lancées en tant qu'administrateur.

    Procédure de base

    • Fixer et brancher le SSD dans l’ordinateur

    • Désactiver Windows FastStart (cf votre moteur de recherche préféré)

    • Initialiser et partitionner le disque à l'aide de Windows

      • Démarrer sur le Windows installé ou WinPE
      • Pour initialiser le disque, d'abord créer une table de partition, puis partitionner le disque. Pour ce faire :
        • Suivre les instructions de partitionnement UEFI/GPT selon Microsoft. Ci-dessous mon exemple, mais peut-être avez-vous besoin d'une partition "recovery" aussi, ou votre configuration nécessite quelques aménagements. Dans ce cas, voir les instructions de Microsoft et adapter pour vos besoins.
        • Par exemple: une partition EFI de 260Mo, une partition Microsoft Reserved (MSR) de 16Mo, une partition pour Windows (taille au moins égale à la taille de la partition de Windows à cloner). Pour informations, dans diskpart, les tailles que vous donnez en MB/Mo sont en réalité des MiB/Mio (220 = 10242 octets).
          • Ouvrir une invite de commande en mode administrateur et lancer diskpart . Et une fois dans diskpart :
            • list disk pour lister les disques et connaître le n° du SSD.
            • select disk # avec le numéro du SSD à la place de #
            • clean Supprime le contenu du disque / l'initialise
            • convert gpt Définit que le disque aura une table de partition GPT
            • create partition efi size=260 Crée une partition EFI de 260MiB
            • format quick fs=fat32 label="System" Formater la partition EFI au format FAT32
            • assign letter="S" Lui donner la lettre S
            • create partition msr size=16 Créer une partition Microsoft Reserved de 16MiB
            • create partition primary Créer la partition pour Windows (l'équivalent du C: )
            • format quick fs=ntfs label="Windows" Formater la partition pour Windows au format NTFS
            • assign letter="N" Lui donner la lettre N
            • list volume Liste les volumes. Permet de voir la table de partition.
            • exit Quitte diskpart
    • Cloner le Windows installé sur le HDD. Ceci sera fait à l'aide de
      Clonezilla

      • Redémarrer dans Clonezilla
      • Une fois dans clonezilla, et si vous êtes confortable avec les lignes de commande Linux, éventuellement supprimer de la partition Windows du HDD les fichiers pagefile.sys , hyberfil.sys (désactiver windows faststart avant), swapfile.sys .
      • Cloner la partition Windows du HDD vers le SSD (de préférence, partition de même taille, et de toutes façons, la partition de destination doit être plus grande que la source. Si ce n'est pas le cas, réduisez d'abord la taille de votre partition Windows depuis Windows). Dans clonezilla, utiliser le mode Partition vers Partition, et en mode Export. Utiliser les options -e1 auto (automatically adjust file system geometry for a ntfs boot partition if exists) -e2 (sfdisk uses CHS of hard drive from EDD (for non grub loader) -r (resize filesystem to fit partition size of target) -m (do NOT clone boot loader) -v (verbose)
      • Optionnellement cacher la partition contenant le windows source de la table de partition du disque source (si vous ne savez pas à quoi ça sert, passez votre chemin). Pour cela modifier le type de partition de la partition NTFS de windows (en principe, NTFS a un id de « 7 ». On peut utiliser id 17 pour la partition cachée : 17 correspond à « IFS Hidden »). Utiliser cfdisk ou fdisk pour faire ce changement (ce sont des programmes linux).
    • Dans le Firmware UEFI (ou BIOS-UEFI), on peut en profiter pour passer
      du mode SATA "IDE" vers "AHCI". Windows n'aime pas ce changement et
      il faut donc faire une opération dans le registre qui est
      détaillée ci-dessous. Tant que vous ne le faites pas, vous aurez un
      écran de plantage bleu de windows au démarrage (BSOD).

    • Si vous voulez être sûr de ne pas faire de bêtise dans le Windows que
      vous venez de cloner, je vous conseille d'éteindre l’ordinateur & de
      débrancher l’ancien disque. Ainsi vous ne risquez pas de modifier le
      mauvais fichier de registre (en l'occurrence celui de votre Windows
      sur le HDD)

    • Effectuer quelques opérations sur le Windows de destination (celui
      sur le SSD) avant qu'on ne démarre dessus. En particulier corriger le
      registre pour affecter la lettre de lecteur C: à la bonne partition,
      et si le paramétrage du Firmware UEFI (BIOS-UEFI) a été modifié pour
      passer de SATA Mode PCI vers AHCI, on va aussi faire ce changement
      pour que ca fonctionne.

      • Redémarrer dans WinPE (en Mode UEFI, pas MBR !)
        • Tout d'abord déterminer la lettre de lecteur affectée au clone de Windows, celui qui est sur le SSD. Ou, s'il n'y a pas de lettre affectée, lui en donner une, par exemple N: (lettre utilisée dans les exemples qui suivent)
          • Pour cela, lancer dans diskpart
            • list volume
              Ce qui retourne la liste des volumes avec la lettre de lecteur qui a été affectée à chacun.
          • Si aucune lettre de lecteur n'est affectée, il faut alors lui en affecter une. Pour cela, lancer dans diskpart
            • select volume # (avec # étant le numéro du volume qui contient le nouveau windows)
            • assign letter=N
              S'il n'est pas possible d'utiliser select volume alors faire comme ceci
            • list disk
            • select disk # (# étant le numéro affecté au SSD)
            • list partition
            • select partition # (# étant le numéro affecté à la partition de Windows sur le SSD, probablement 3)
            • assign letter=N
        • Faire un CHKDSK /F sur la lettre du nouveau Win
        • Pour que la partition C: utilisée par Windows soit celle du SSD et pas celle de l’ancien disque, modifier une clé de registre du nouveau Windows :
          • Lancer REGEDIT et dans le registre HKEY_LOCAL_MACHINE monter la ruche N:\Windows\System32\Config\SYSTEM . Lui donner le nom "NewWin" On s’intéresse à HKEY_LOCAL_MACHINE\NewWin\MountedDevices . Ce sont là les valeurs qui sont dans le registre " HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices " lorsqu'on est dans l'installation de Windows.
            • Dans HKEY_LOCAL_MACHINE\NewWin\MountedDevices modifier la lettre de lecteur C: en renommant \DosDevices\C: par \DosDevices\O: (car la valeur fait référence à la partition de l'ancien Windows sur le HDD et on ne veut pas, en démarrant, utiliser cette partition mais celle de son clone qui est sur le SSD). Ainsi, lorsqu'on démarrera dans le nouveau Windows, la partition contenant le Windows sur le HDD aura la lettre O:, et la partition contenant le Windows sur le SSD aura la lettre C:
            • Créer une nouvelle valeur binaire nommée \DosDevices\C: et lui donner comme contenu celui de \DosDevices\N: qui est renseignée dans le registre WinPE, c'est-à-dire là HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices ( C: étant la lettre qu'utilisait le Windows du HDD comme partition où il y a le dossier \Windows )
            • ATTENTION: Bien vérifier que la copie a fonctionné et qu'il y a les bonnes valeurs, car dans mes essais, j'ai du m'y reprendre à 2 fois car le 1er "coller" ne collait pas ce que je voulais.
            • En principe c'est tout. Mais d'après certaines sources, il y aurait une clé \\?\Volume{GUID} ayant le même contenu que le \DosDevices\O: qu’on vient de modifier. Chez moi ce n'était pas le cas. Si vous avez une telle valeur, alors il faut lui donner le contenu de \DosDevices\N: depuis le registre WinPE
        • Si en même temps que la migration on veut aussi passer du mode SATA IDE vers AHCI alors il faut encore faire ceci. Cela a été repris du site tomshardware.co.uk
          • Toujours dans REGEDIT avec la ruche montée en HKEY_LOCAL_MACHINE\NewWin
          • Aller à HKEY_LOCAL_MACHINE\NewWin\ControlSet000\Services\storahci\StartOverride
          • Changer la valeur DWORD de 3 à 0.
          • Au redémarrage, si ça n'a pas été fait, changer la paramétrage du contrôleur SATA de IDE à AHCI. Au redémarrage, Windows devrait directement démarrer correctement et sans plantage (BSOD).
        • Rendre le disque bootable en installant les outils EFI de microsoft et configurant le Magasin BCD (BCD Store)
          • D'abord assigner une lettre de lecteur à la partition ESP
            • MOUNTVOL S: /S
              Si ca n'a pas fonctionné, faire comme ceci dans diskpart
            • list disk
            • select disk # (# est le numero du SSD retourné par list disk)
            • list partition
            • select partition # (# est probablement 1)
            • assign letter=S
          • Puis lancer bcdboot N:\windows /l fr-fr /s S: /f UEFI
            • N:\Windows est le répertoire contenant le clone de Windows sur le SSD)
            • S: = partition EFI
    • Redémarrer, et avant le lancement de Windows vérifier votre UEFI
      (ou BIOS-UEFI). Il faut qu'il soit configuré pour démarrer par défaut
      en mode UEFI et pas en mode BIOS. Penser aussi à corriger le
      paramétrage SATA si cela a été modifié dans le registre de Windows.

      Le paramétrage du démarrage avec
      bcdboot N:\windows /l fr-fr /s S: /f UEFI a normalement créé le
      magasin BCD, mis tous les fichiers EFI sur la partition SYSTEME (ESP,
      partiton EFI, la 1ère du SSD) et dit au firmware UEFI qu'il doit
      automatiquement démarrer avec le gestionnaire de démarrage
      (boot manager) de Windows.

    • Une fois qu’on a réussi à démarrer dans la copie de Windows

      • Réactiver le "FastBoot"
      • Réactiver l'environnement de récupération de Windows en lançant, depuis une ligne de commande avec les droits administrateur, la commande reagentc.exe /enable . Vérifier avec reagentc.exe /info . Et s'il y a une erreur essayer avec reagentc.exe /enable /setreimage /path C:\Recovery\WindowsREC:\Recovery\WindowsRE est le dossier où se trouve le fichier Winre.wim
      • Vérifier que tout est en ordre. Eventuellement donner un nouveau nom à votre partition C: (pour la différencier de celle sur le HDD) en lançant: LABEL [drive:][label]
      • Redémarrer encore une fois en laissant le processus de démarrage se faire tout seul pour vérifier que tout est ok.
    • Réinsérer l'ancien disque dur.

    • Normalement, il devrait être possible de redémarrer dans l'ancien
      Windows, du moment que vous savez comment booter en MBR, et sous
      réserve de ne pas avoir modifié le mode SATA dans le UEFI/BIOS. SI
      c'est le cas, vous pouvez envisager de modifier le registre du
      Windows du HDD, ou de modifier le paramétrage du UEFI/BIOS.

      Si vous avez aussi Linux d'installé sur le HDD, il devrait toujours
      être possible de le démarrer en mode BIOS

    • On peut diminuer/augmenter la taille de la partition C: du SSD (Pour
      un SSD TLC ou VNAND, on peut par exemple laisser de l’espace libre à
      la fin ~10 % de la capacité du disque d'après le logiciel Samsung
      Magician, pour un SSD 860 EVO)

    • En principe, puisqu’on boot en EFI on peut enlever sur le clone
      Windows sur le SSD les fichiers \bootmgr et \Boot\BCD puisque ce
      sont ceux qui étaient utilisés pour un boot en mode BIOS/MBR et que
      désormais on est en EFI. Vous pouvez d'abord les renommer et vérifier
      que ca ne change rien au prochain boot, plutôt que de les supprimer
      tout de suite.

    Quelques pistes si ça ne fonctionne pas…

    • Faire un chkdsk sur la nouvelle partition
    • Recréer le bootsector du NTFS avec testdisk (dispo sur System Rescue CD, mais peut être aussi dans Clonezilla ? Je n'ai pas vérifié)
    • Vérifier le BCD:
    • Vérifier que la partition EFI est bien initialisée (présence des fichiers \EFI , \EFI\Boot\ , \EFI\Microsoft\ …) Si ce n'est pas le cas, il y a eu un problème avec bcdboot N:\windows /l fr-fr /s S: /f UEFI
    • Vérifier le boot manager du bios (démarrage en UEFI ou MBR ? Gestionnaire de démarrage par défaut ? Présence du gestionnaire de démarrage de Windows ?)
    • A priori, pas utile : Commandes à lancer dans WinPE
      • Pour recréer le boot sector de la partition systeme (EFI): bootrec /fixboot
      • Pour chercher les OS sur le disque et les mettre dans le bootloader bootrec /scanos
    • Quelques commandes de bcdedit pour modiser la valeur de certains éléments du magasin BCD. Inutile car le BCD Store qui est utilisé lorsqu'on démarre en mode EFI n'est pas le même que celui utilisé dans un démarrage en mode MBR. Donc, pas besoin de chercher à modifier le BCD. Je garde pour info : les lettres sont celles telles que définies dans le système où on est (WinPE par ex). Doc BCDEDIT
      • bcdedit /set {bootmgr} device \Device\HarddiskVolume1
      • bcdedit /set {default} device \Device\HarddiskVolume3
      • bcdedit /set {default} osdevice \Device\HarddiskVolume3
      • Ou à la place de \Device\HarddiskVolume1 mettre les lettres de lecteur :
      • bcdedit /set {bootmgr} device partition=S:
      • bcdedit /set {default} device partition=C:
      • bcdedit /set {default} osdevice partition=C:

    Documentation, pour aller plus loin…

    A propos du EFI/UEFI:

    A propos de l'entrée MountedDevices du registre:
    http://diddy.boot-land.net/firadisk/files/mounteddevices.htm

    Si on veut y accéder, par défaut les fichiers du BCD sont cachés. Pour
    les rendre visibles:

    • attrib bcd -s -h -r
    • mv bcd bcd.bak
    • bootrec /rebuildbcd

    Documentation bcdedit:

    MBR Partition ID

    A propos des disk ID (=Disk signatures):

    Si besoin de supprimer du registre les entrées de disques qui ne sont
    pas connectés ou sans lettre assignée lancer: mountvol /R. Ce
    programme permet aussi de lister les lettres de volumes avec leur GUID
    (GUID pour ce système uniquement, il n’est pas stocké dans la partition,
    ni ailleurs sur le disque, il est assigné par windows pour un couple
    (signature de disque/partition offset) dans une instance de windows
    alors que dans une autre instance de windows la même partition sur le
    même disque aura ce GUID différent)

    Changer le label du volume: commande LABEL [drive:][label]

    Historique de révisions

    • Vous trouverez la dernière version de ce tutoriel sur ma page perso
      de tutoriels informatique
      .
      Vous y trouverez aussi la version HTML, PDF et TXT.

    • 2018-06-17 : Ajout d'une note indiquant que ce tutoriel utilise des
      logiciels libres

    • 2018-06-11 : Correction de la forme et de fautes d'orthographe

    • 2018-05-28

    Commentaires : voir le flux atom ouvrir dans le navigateur

  • Rumeurs sur l'hyper-threading - TLBleed (Journaux LinuxFR)

    La peinture de la dépêche sur la faille Lazy FPU save restore n'étais pas encore sèche
    que je tombais sur de curieux messages conseillant de désactiver l'Hyper-threading.

    Suivis de conversations plus ou moins inquiétantes sur Twitter et dans les mailings list.

    Accroche toi au pinceau

    Un commit sur OpenBSD désactive l' Hyper-treading par défaut.
    Le message associé est explicite:

    « Since many modern machines no longer provide the ability to disable Hyper-threading in
    the BIOS setup, provide a way to disable the use of additional
    processor threads in our scheduler. And since we suspect there are
    serious risks, we disable them by default
     »
    Puisque les machines récentes ne donnent plus la possibilité de désactiver l' Hyper-threading depuis le BIOS, trouvez un moyen de désactiver l'utilisation des threads d'un processeur dans notre ordonnanceur.
    Et comme on suspecte que le risque est sérieux, désactivons le par défaut.

    Pour faire plus court, j'avais lu auparavant un laconique:

    ps deactivate Hyper-threading on your server
    Désactivez l'Hyper-threading sur vos serveurs !

    Venant des équipes OpenBSD, il y a de quoi s'interroger.

    J'enlève l'échelle

    La conférence Black Hat qui se déroulera en août prochain, propose au menu:

    « This therefore bypasses several proposed CPU cache side-channel protections. Our TLBleed exploit successfully leaks a 256-bit EdDSA key from libgcrypt (used in e.g. GPG) with a
    98% success rate after just a single observation of signing operation on a co-resident hyperthread and just 17 seconds of analysis time
     »
    En outre, ceci court-circuite plusieurs protections sur le cache. Notre exploit TLBeed a réussi à voler une clef 256-bit EdDSA depuis ligcrypt (utilisée par GPG ) dans 98% des tentatives, après une simple observation des opérations de signature depuis un thread tournant sur le même CPU en seulement 17 secondes d'analyse.

    Colin Percival, auteur en 2005 de:

    1. un papier sur les attaques via les caches, Cache Missing for Fun and Profit
    2. un article qui cible plus particulièrement les risques liés à l'Hyper-threading

    en remet une couche:

    « I think it's worth mentioning that one of the big lessons from 2005 is that side channel attacks become much easier if you're executing on the same core as your victim »
    Je pense qu'il est bon de rappeler cette grande leçon de 2005: une attaque en side channel est tellement plus facile si vous l'exécutez sur le même cœur que votre victime.

    Cuisine

    Intel n'est jamais clairement impliqué; mais je précise, comme ça, en passant, que l'Hyper-Threading est une implémentation Intel du Simultaneous Multi Threading.
    Il s'agit de faire exécuter en parallèle, sur un même cœur, plusieurs unités fonctionnelles ou de calcul.
    Et pour rendre cette technique efficace et moins gourmande en ressource, cette implémentation partage aussi les caches mémoires.

    Keep systems protected, efficient, and manageable while minimizing impact on productivity

    Conclusion

    Toutes les solutions de sécurité aujourd’hui ne sont que des châteaux forts construit sur du sable.

    Si encore une fois, la désactivation de l'Hyper-threading pourrait même avoir des effets positifs sur les performances, autant en finir une fois pour toute.

    Retour aux origines:

    • un partage complet sans protection des ressources
    • plus de mode protégé
    • pas même de segmentation mémoire

    Vos machines iront encore plus vite. Enfin, j'espère.

    Commentaires : voir le flux atom ouvrir dans le navigateur

  • Surface d'attaque des serveurs dans les nuages (cloud) (Journaux LinuxFR)

    Passionnant et très utile article sur le blog en anglais de James Bottomley (merci LWN.net pour le résumé) : il étudie la sécurité des solutions d'hébergement Cloud en se basant sur la solution retenue : serveurs dédiés, serveurs partagés, serveurs virtuels, conteneurs, et en comparant les profils d'attaques verticales et horizontales.

    Comme vous aimez les conclusions rapides, sachez déjà que la solution conteneurs l'emporte haut la main.

    Une attaque verticale c'est du code traversé : de la requête web à la base de donnée jusqu'à la réponse dans le navigateur ou l'application, et qui contient potentiellement des bugs, elle concerne uniquement votre hébergement :

    all code that is traversed to provide a service all the way from input web request to database update to output response potentially contains bugs; the bug density is variable for the different components but the more code you traverse the higher your chance of exposure to exploitable vulnerabilities. We’ll call this the Vertical Attack Profile (VAP) of the stack.

    Une attaque horizontale par contre peut se propager d'hébergement en hébergement :

    In an IaaS cloud, part of the vertical profile belongs to the tenant (The guest kernel, guest OS and application) and part (the hypervisor and host OS) belong to the CSP. However, the CSP vertical has the additional problem that any exploit in this piece of the stack can be used to jump into either the host itself or any of the other tenant virtual machines running on the host. We’ll call this exploit causing a failure of containment the Horizontal Attack Profile (HAP).

    La surveillance est répartie différemment selon l'hébergement, par exemble sur un serveur partagé l'hébergeur doit surveiller toute la pile : le matériel, le noyau, les librairies et le middleware, vous n'êtes responsable que de la couche applicative, tandis qu'avec un conteneur il surveille le matériel et le noyau hôte.

    Mais les attaques sont aussi réparties différemment. Dans un hébergement partagé, si vous attaquez le noyau vous pouvez compromettre tout le système, donc tous les hébergements tandis qu'il est plus difficile de sortir d'un conteneur.

    Compte tenu de quelques autres facteurs que je ne résume pas ici — veuillez lire cet article avant de commenter —, les équipes de sécurité de l'hébergeur bossent « mieux » avec des conteneurs, qui sont donc plus fiables, quoi qu'en dise votre contrat. Mais que ça ne vous dispense pas des opérations habituelles de base : backup, backup ET backup (sauvegarde, sauvegarde ET sauvegarde de leurs petits noms).

    Commentaires : voir le flux atom ouvrir dans le navigateur

  • Livre O'Reilly en téléchargement gratuit légal (Journaux LinuxFR)

    Journal bookmark : O'Reilly propose de télécharger gratuitement une centaine d'ouvrages, de tous domaines : IoT, Sécurité, Programmation, Management…

    C'est par ici : http://www.oreilly.com/free/reports.html

    Lire les commentaires

  • Revue de presse de l'April pour la semaine 24 de l'année 2018 (Dépêches LinuxFR)

    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

    [Numéro Magazine] Portrait de l’artiste en hackeur qui détourne les nouvelles technologies
    Par Ingrid Luquet‐Gad, le jeudi 14 juin 2018. Extrait :

    « Algorithmes, codage, datas, hardware… comment les artistes détournent‐ils les nouvelles technologies ? C’est la question vertigineuse à laquelle répond une double exposition au centre Pompidou, avec l’artiste japonais Ryoji Ikeda en invité d’honneur. »

    [France Culture] Que reste‐t‐il du logiciel libre ?
    Par Hervé Gardette, le mercredi 13 juin 2018. Extrait :

    « Microsoft vient de racheter la plate‐forme de création collaborative de logiciels GitHub. Est‐ce vraiment une bonne nouvelle pour le logiciel libre ? Et quelles conséquences pour les utilisateurs ? La philosophie du libre a‐t‐elle gagné ou s’est‐elle fait manger ? »

    Et aussi :

    [RFI] Software Heritage, la grande bibliothèque du logiciel
    Par Dominique Desaunay, le mercredi 13 juin 2018. Extrait :

    « La plupart des activités humaines dépendent exclusivement des programmes informatiques qui permettent, par exemple, aux internautes de consulter leurs réseaux sociaux ainsi que de surfer sur n’importe quelle page Web. Des logiciels fragiles qui contrairement aux hiéroglyphes gravés dans la pierre peuvent s’altérer avec le temps et disparaître à jamais. C’est la raison pour laquelle les informaticiens de l’Institut national de recherche en informatique et en automatique ont développé une immense bibliothèque en ligne dénommée Software Heritage. »

    Et aussi :

    [Numerama] Open source : qui sont les bons élèves et les cancres parmi les géants de la tech ?
    Par Victoria Castro, le mardi 12 juin 2018. Extrait :

    « Tout le monde dit aimer l’open source, mais qu’en est‐il vraiment ? Nous avons dressé un classement de 6 géants de la tech, du plus grand sympathisant de l’ouverture au plus propriétaire d’entre eux. »

    [BFMtv] Pourquoi les mèmes sur Internet sont en danger
    Par Elsa Trujillo, le lundi 11 juin 2018. Extrait :

    « L’article 13 d’un projet de directive européenne sur le droit d’auteur entend limiter drastiquement la réutilisation de contenus protégés. »

    Et aussi :

    Voir aussi :

    Commentaires : voir le flux atom ouvrir dans le navigateur

  • LinuxFr.org : seconde quinzaine de mai 2018 (Journaux LinuxFR)

    Nonante-septième épisode dans la communication entre les différents intervenants autour du site LinuxFr.org : l’idée est tenir tout le monde au courant de ce qui est fait par les rédacteurs, les admins, les modérateurs, les codeurs, les membres de l’association, etc.

    L’actu résumée ([*] signifie une modification du sujet du courriel) :

    Avertissement

    Ceci est un second message pour prévenir certains de nos visiteurs qui nous transmettent inutilement des infos sensibles via leur lecteur de flux RSS/Atom, infos qui se retrouvent stockées dans nos logs web.

    Format par défaut d'un log du serveur web Nginx (source) :

    log_format combined '$remote_addr - $remote_user [$time_local] '
                        '"$request" $status $body_bytes_sent '
                        '"$http_referer" "$http_user_agent"';
    

    Certains utilisateurs nous transmettent leur nom d'utilisateur distant (pas forcément gênant, mais inutile).

    Par contre, certains nous transmettent leur nom d'utilisateur ET leur mot de passe. On a ainsi leur nom d'utilisateur dans le champ remote_user mais aussi leur nom d'utilisateur et leur mot de passe en clair dans le champ http_referer, sous la forme http://login:pass@linuxfr.org/journaux.atom ou https://login:pass@linuxfr.org/news.atom. Cela concerne 6 utilisateurs différents (tous utilisateurs de FreshRSS), dont 1 a été identifié et contacté en privé. Pour les cinq autres, à savoir Jeoffrey, jm, lionel, SVNET et titoko, je vous suggère d'arrêter de nous envoyer votre mot de passe, puis de changer de mot de passe étant donné qu'il a fuité, et aussi d'utiliser préférentiellement la version HTTPS du flux souhaité. N'hésitez pas à me contacter en privé si vous avez des questions (oumph CHEZ linuxfr.org).

    La version FreshRSS 1.11.0 du 2018-06-03 corrige ce problème Strip HTTP credentials from HTTP Referer in SimplePie #1891.

    Statistiques

    Du 16 au 31 mai 2018

    • 1371 commentaires publiés (dont 11 masqués depuis) ;
    • 344 tags posés ;
    • 99 comptes ouverts (dont 9 fermés depuis) ;
    • 33 entrées de forums publiées (dont 1 masquée depuis) ;
    • 32 liens publiés (dont 1 masqué depuis) ;
    • 26 dépêches publiées ;
    • 30 journaux publiés (dont 1 masqué depuis) ;
    • 3 entrées nouvelles, 1 corrigée dans le système de suivi ;
    • 0 sondage publié ;
    • 2 pages wiki publiées (dont 1 masquée depuis).

    Listes de diffusion (hors pourriel)

    Liste webmaster@ - [restreint]

    • R.A.S.

    Liste linuxfr-membres@ — [restreint]

    • R.A.S.

    Liste meta@ - [restreint]

    • R.A.S.

    Liste moderateurs@ - [restreint]

    • [Modérateurs] Dépêche Refaire linuxfr
    • [Modérateurs] contenu problématique
    • [Modérateurs] nfsw
    • [Modérateurs] URL d'une dépêche

    Liste prizes@ - [restreint]

    • R.A.S.

    Liste redacteurs@ - [public]

    • R.A.S.

    Liste team@ - [restreint]

    • [team linuxfr] Optimize MySQL
    • [team linuxfr] Login/mot de passe envoyé en clair dans une URL HTTP sur LinuxFr.org
    • [team linuxfr] Login/mot de passe envoyé en clair dans une URL HTTP sur LinuxFr.org
    • [team linuxfr] Login/mot de passe envoyé en clair dans une URL HTTP sur LinuxFr.org
    • [team linuxfr] Test passage en Jessie
    • [team linuxfr] Joker.com: Your domains are about to expire (expiration report)

    Liste webmaster@ — [restreint]

    • R.A.S.

    Canal IRC adminsys (résumé)

    • mises à jour de sécurité
    • le support sécurité normal pour Debian GNU/Linux 8 Jessie s'arrête au 17 juin
    • expiration du certificat au 3 juin et discussion sur le renouvellement
    • deux conteneurs mis à jour en Jessie, en attendant le passage en Stretch
    • le conteneur de développement redirige tout le trafic en HTTPS désormais
    • une boucle de courriels entre un système de ticket et notre gestionnaire de liste de diffusion
    • travaux en cours pour nettoyer le dépôt git d'administration système (avec des fichiers générés par l'outil d'automatisation Ansible notamment)

    Tribune de rédaction (résumé)

    • Migration de GIMP vers GitLab ajoutée dans la dépêche sur la 2.10.2
    • Demande de retours sur la dépêche GrafX2 par le développeur principal
    • Une correction post-publication

    Tribune de modération (résumé)

    • du spam (dont un robot réutilisant des extraits de phrases)
    • modération d'une image déplacée
    • expiration de notre certificat X509 Gandi Wildcard au 3 juin
    • évocation du renouvellement du CNNum (on aurait pu mentionner les entrées au comité de prospective de la CNIL)
    • migration de deux conteneurs en Debian Jessie

    Commits/pushs de code https://github.com/linuxfrorg/

    • Merge pull request #222 from fredplante/master
    • Fix typo
    • (svgtex) fixes duplicate xlink attribute on svg result
    • (epub) Use https for LinuxFr.org URLs

    Divers

    • Geek Faëries du 1 au 3 juin : conférence « LinuxFr.org, 20 ans que ça geeke » et table ronde « Ces plates‐formes du Libre qui soutiennent les communautés » avec l'Agenda du Libre et En Vente Libre. Plein de mercis à Bookynette pour le Village du libre, à l'équipe organisatrice des GF, et à Marco et Marius pour l'hébergement.
    • Proposition de conférence soumise + table ronde + demande de stand pour les RMLL 2018 Strasbourg

    Commentaires : voir le flux atom ouvrir dans le navigateur

  • Le logiciel libre dont on ne peut utiliser les libertés (Journaux LinuxFR)

    Sommaire

    Dans mon entreprise, on utilise des logiciels libres. Il arrive qu'on aie besoin de modifier ces logiciels tiers, pour gérer un cas spécifique ou pour une meilleure intégration dans l'application.

    Et parfois, en se lançant dans ce genre de travaux, on tombe sur une surprise :

    Il existe des logiciels libres dont il est presque impossible d'utiliser les libertés sans une quantité déraisonnable de travail.

    Je ne parle pas d'openwashing ici, cette technique qui consiste à faire croire qu'un logiciel est libre mais ne l'est pas et dont on a récemment parlé ici. Non, je parle de programmes véritablement libres (sous licence Apache ou MIT généralement, notre code n'étant pas libre ça ne peut être des licences contaminantes comme la GPL) mais dont les subtilités font que… visiblement quelqu’un ne veut pas que les libertés soient trop utilisées. On notera déjà que c'est souvent des logiciels dont il existe une version avancée commerciale.

    Les libertés d'exécution et de redistribution sont généralement faciles à appliquer ; le problème survient souvent quand on veut étudier le programme et l'améliorer. Voici quelques exemples de techniques utilisées ; certaines peuvent être expliquées par un simple manque de volonté d'adhérer à l'esprit du logiciel libre ou par une mauvaise organisation interne ; d'autres s'approchent du sabotage. Dans tous les cas, la licence est respectée à la lettre.

    Toutes les techniques ci-dessous ont été croisées dans des cas réels (heureusement pas toutes sur le même projet) :

    Aucune documentation technique

    Il n'existe aucune documentation technique d'aucune sorte. Selon la taille du logiciel, ça peut être plus ou moins gênant (je vous laisse imaginer quand le workspace du projet fait plusieurs centaines de Mo).

    Parfois, rien qu'obtenir une version exécutable du logiciel à partir des sources est un calvaire.

    Une version avancée consiste à utiliser des frameworks, compilateurs ou réglages exotiques, sans que ce soit documenté publiquement.

    Les dépendances cachées

    Les dépendances du projet vont par défaut se télécharger depuis un serveur qui appartient à la même organisation que le projet, et pas depuis les dépôts standards. Et surprise, ce serveur ne contient (en public) que les dernières versions des dépendances.

    Au pire, ces dépendances sont elles-mêmes libres, on peut toujours aller les chercher et les compiler à la main, mais la quantité de travail pour obtenir une version fonctionnelle explose dès qu'on veut autre chose que la toute dernière version. Et je ne parle pas de la galère quand on veut mettre à jour un fork depuis l'origine.

    Le faux dépôt de sources

    Celle-ci est subtile : le dépôt des sources public n'est d'évidence pas un dépôt de travail, puisqu'il ne contient qu'un seul commit par version, sans le moindre commentaire. Ça n'est pas gênant tant qu'on essaie pas de maintenir un fork.

    La version avancée, qui consiste à ne fournir les sources que sous la forme d'un dossier compressé sans le moindre historique, semble avoir à peu près disparue, du moins dans mon domaine.

    Le tapis et le labyrinthe mouvant

    Deux variantes d'une même technique :

    1. Les sources peuvent être planquées à un endroit inaccessible, voire carrément absentes du site éditorial – rien, pas même un lien, pas même une mention claire de la licence : si tu ne sais pas déjà que le logiciel est libre… tu le découvres en lisant la licence après avoir donné toutes tes informations pour la fameuse « version de démonstration 30 jours ».
    2. Le site change tout le temps, et la manière d'accéder aux sources n'est jamais la même d'un mois sur l'autre.

    À noter que quelques entreprises ne fournissent les sources qu'aux clients de l'entreprise, ce qui est généralement autorisé.

    Une variante intéressante du point 2, c'est quand le logiciel change régulièrement de grands pans de son architecture.

    Le code qui fait des suppositions sur l'environnement de développement

    Généralement à base de chemins en dur dans le code ou de réglages spécifiques à un IDE. C'est rare, mais on en croise…

    La ressource libre-mais-déposée

    Ici ça s'applique plus aux ressources qu'au code, principalement aux logos : votre ressource est libre, mais est une marque déposée. Il y a plein de cas où on ne peut pas l'utiliser. Par exemple, le logo GNU n'illustre pas la version d'origine de cet article, parce que, je cite (le gras est d'origine) :

    Ce dessin est utilisable conformément à la GNU FDL v1.3, à la licence Art libre ou à la Creative Commons CC-BY-SA 2.0 (résumé en français ici). Toutefois, c'est aussi un logo déposé du projet GNU. Si vous voulez vous servir de cette tête de GNU pour mettre en lien un site web de la Free Software Foundation ou du projet GNU, n'hésitez pas ; de même, vous n'avez pas besoin de permission supplémentaire pour l'utiliser dans des contextes qui parlent de GNU de manière positive et exacte. Pour tout autre usage, veuillez au préalable demander la permission à licensing@fsf.org.
    Source: La page du logo GNU sur le site de la FSF

    Et donc ce logo est disponible sous 3 licences libres différentes, mais a des restrictions très fortes sur l'usage qui peut en être fait. C'est en fait valable avec à peu près tous les logos et toutes les marques – et les règles d'utilisations de logos et marques d'entreprises peuvent être bien plus restrictives.


    La conclusion de tout ceci ?

    Qu'un logiciel soit libre n'impose pas que son développeur doive vous faciliter l'application des libertés.

    C'est quelque chose qu'on croit trop souvent, de même qu'on mélange souvent « libre » et « gratuit ».


    Ce texte, placé sous licence CC BY 4.0, est une légère adaptation pour LinuxFR.org de l'original disponible sur Zeste de Savoir.

    Commentaires : voir le flux atom ouvrir dans le navigateur

  • L'État français adopte Matrix/Riot (Journaux LinuxFR)

    Ça m'étonne de n'en avoir encore rien lu ici alors que d'ordinaire, je ne suis pas celui qui suit les actualités de Matrix de si près.

    D'après les récentes informations relayées par NextInpact, mais aussi un peu partout dans les médias, comme ici, dans le Monde Informatique, l'État français compte se doter d'ici cet été de son propre système de messagerie instantanée.

    Et ce service sera basé sur Matrix/Riot!

    De ce que je comprends le choix s'est fait sur les critères suivants:

    • indépendance vis-à-vis de toute entreprise, ça nécessite donc un système décentralisé
    • messagerie, voix et vidéo
    • apparemment multiplateforme, vu que j'ai cru voir passer (oui, ça c'est de l'info solide) des références au soutien du projet dans les activités Riot-Mobile
    • chiffrement bout-à-bout

    C'est évidemment un formidable coup de pub pour Matrix, Riot et New Vector, la société montée pour poursuivre le développement du projet.
    On ne peut que se féliciter de voir un système Libre et décentralisé réaliser une telle percée.

    Et apparemment d'autres administrations seraient également intéressées: Pays-Bas et Canada, pour ne pas les nommer.
    Tout ça pourrait bien faire boule de neige.

    Cela dit, ce succès m'inquiète légèrement aussi, en raison d'un grief que j'ai depuis presque le début contre le protocole lui-même: les salons et tout le trafic sont répliqués sur les serveurs de chaque participant, ce qui permettrait à un salon de survivre si le serveur qui l'a vu naître tombait, mais ce qui entraîne aussi des charges monstrueuses pour les serveurs légers dès qu'un salon devient trop fréquenté.

    Conséquence: un "petit" serveur est de facto exclu des salons les plus populaires, et c'est assez pénible pour tous ceux qui sont auto-hébergés ou disposent d'un serveur personnel.

    Cette situation pourrait s'améliorer grandement avec l'arrivée de Dendrite, le nouveau serveur écrit en Go qui remplacerait l'unique serveur de production actuel Synapse, écrit en Python.

    À suivre!

    Commentaires : voir le flux atom ouvrir dans le navigateur

  • Oui, mais si on oublie la réponse à sa question secrète ? (Journaux LinuxFR)

    Bonjour à tous,

    Comme moi, peut-être vous-êtes vous un jour posez cette question : « que se passe-t-il si je n'ai plus accès à ma boîte mail et que je ne me rappel plus de la réponse à ma question secrète » ? Et, comme moi, peut-être l'avez vous refoulée bien vite en vous disant que de toute manière cela ne vous arriverai jamais. Aujourd'hui, j'ai la réponse à cette question en ce qui concerne les comptes Yahoo et je tenais à vous en faire part tant elle est étonnante.

    Tout d'abord, les faits : ma mère (ben oui, vous pensiez franchement que cela arriverait à un Linuxien chevronné ? :p) dispose d'un compte Yahoo depuis plusieurs années et utilise Outlook pour rapatrier et envoyer ses courriels. Seulement voilà, à cause d'une mauvaise manipulation dont j'ignore encore la nature, son adresse a été subtilisée et utilisée pour envoyer des tonnes de pourriels. Aussi, nous nous sommes rendus sur le site de Yahoo, et avons tenté de nous connecter, mais cette possibilité nous a été refusée sans répondre à une question secrète. Évidemment, la question et sa réponse datant d'il y a plusieurs années et ces dernières n'ayant jamais servi, il nous a été impossible de remettre la main dessus…

    Dès lors, que faire sachant qu'il était exclus d'abandonner ce compte ? Hé bien, il nous était possible de demander de l'aide par courriel (j'attends toujours une réponse, d'ailleurs). Cependant, comme cela était un peu urgent, nous avons tenté de joindre Yahoo par téléphone. En effet, après une brève procédure nous demandant de décrire notre problème et de fournir une autre adresse courriel, en plus d'envoyer notre demande afin qu'elle soit (peut-être) traitée, nous avons eu droit à un joli numéro de téléphone (français) nous précisant que leurs bureaux ne sont ouvert que de 9h00 à 17h00. Comme il était plus de 20h00 lorsque nous avons lu cela, nous avons attendu le lendemain.

    Le lendemain, nous essayons de joindre Yahoo à l'aide du numéro de téléphone fourni, mais ce dernier sonne constamment occupé. Dans le doute, nous appelons les renseignements (oui, cela existe encore) et un monsieur fort aimable nous précise qu'il est impossible de joindre Yahoo à l'aide de ce numéro et qu'en vérité, il est nécessaire de les joindre à leur siège social qui est situé, je vous le donne en mille, à Dublin

    Qu'à cela ne tienne, nous tentons le coup (de téléphone) et obtenons une dame à l'autre bout du fil qui ne parle évidemment pas français. Et c'est là que cela devient (enfin) intéressant : après une brève explication du problème, elle nous demande simplement une autre adresse courriel qu'elle place dans les paramètres du compte indisponible comme adresse de secours. Après quoi elle nous envoie un code nous permettant de réinitialiser le mot de passe et les questions secrètes. Cependant, pas une seule fois elle n'a essayé de savoir si nous étions bien les véritable titulaire du compte, par exemple en demandant les derniers courriels reçus ou quelques informations personnels. Rien, juste une autre adresse courriel…

    Ce qui m'amène à me poser une question élémentaire (autre que le coût de cette communication) : qu'est ce qui empêche une personne mal intentionnée de faire de même afin de prendre le contrôle d'un compte dont elle n'est pas l'utilisatrice légitime ? Aussi, comme cela se passe-t-il du côté des autres grands sites comme Google ?

    Lire les commentaires

  • Retour d'expérience d'une petite administration sous linux depuis 8 ans qui fait marche arrière (Journaux LinuxFR)

    Bonjour,

    Suite au journal Munich revient sur windows, j'avais envie de faire un retour sur notre triste expérience de 8 ans sous linux.

    Présentation

    Je suis développeur dans une université, j'ai jusqu'à récemment, responsable d'un tout petit service informatique pour un département (équipe de trois personnes en tout). Lors de mon arrivé en 2010, j'ai eu l'agréable surprise de voir que l'ensemble du parc informatique était sous client léger sous debian (parc étudiant + administratif), sous environ 100 de machines.

    Le déploiement n'avait pas été fait correctement, c'est à dire qu'il n'y avait pas eu information, ni formation auprès des usagers qui évidement ont un peu rallé après la perte de leur cher XP et de leur tour individuelle. Mais après un an, les usagers y étaient habitués.

    Habitués, mais à quoi ?

    A la panne. Le système ne fonctionnait pas. Le serveur d'impression tombait toujours en panne, le serveur PXE ne supportait pas la charge, et pour couronner le tout, il n'y avait pas d'admin système, l'installation avait été faite par un prestataire qui une fois le chèque encaissé se contentait de dire qu'il ne voyait pas d'ou ça pouvait venir. Une petite année plus tard, un collègue remis en état le système, sur des nouveaux serveurs et le tout commençait à tenir la route.

    La suite

    Malgré un système assez stable, on pouvait constater un agacement général du service vis à vis de l'informatique et des "clients légers sous linux". Au début j'avais cru que l'utilisateur était toujours attaché à ses anciennes habitudes de windows mais au bout de trois ans, il était temps de faire l'état des lieux des doléances.

    Années 2013-2014

    • Debian :

    Un des soucis rencontrés était les versions des programmes disponibles. Autant le système était assez stable, autant les logiciels de type Openoffice, Firefox etc n'étaient pas mis à jour (hormis les petits patchs habituels). Les logiciels courants devenaient de plus en plus anciens, et le seul moyen sans risquer de tout casser était de mettre à jour le système principal (avec le risque de tout casser).

    • Openoffice :

    Dans une administration, il y a un énorme usage des outils de bureautique, et notamment du publipostage. Comparaison du même publipostage entre word année 2013 (je ne sais plus la version) et Openoffice sur la même tour dell avec les mêmes données (mais pas les mêmes fichiers) : 20 min pour Word, 8 heures pour Openoffice.

    Niveau ergonomie, Word et Openoffice se ressemblaient énormément, je n'ai pas pas constaté de différences mesurables

    • Administration : Je reviendrais plus tard.

    2014-2016

    On a enfin un admin, il refait tout (entre temps je suis devenu le responsable de la fine équipe), il maitrise tout, on est sur du libreoffice, firefox à jours !!!.
    Et pourtant rien ne change. Toujours les problèmes d'impressions, toujours les problèmes de performance, les mêmes utilisateurs en train de raller, bref hormis le temps d'intervention, c'est toujours absolument un service mauvais qui est rendu à l'utilisateur.

    Pourtant l'équipe informatique et les usagers avaient eu le temps de bien s'y habituer. Pour moi tout venait des clients légers, du réseau etc. Le directeur voulait toujours qu'on reste sous linux avec ce système.

    2016

    La fac déploie les mêmes clients légers (même model) sous windows 7 dans le même étage mais avec des serveurs à plus de 100m (les notre à 25m) et ils fonctionnent nickel. Là c'est la claque. En plus l'admin qui s'occupait de ça n'était pas un admin windows.

    C'est une claque

    2017

    On migre sur des postes classiques Windows 7 avec AD et tout fonctionne nickel.

    Retour

    De mon point de vue voici ce qui manque pour que linux perce dans le desktop en entreprise :

    • Trop de manière de faire (contrairement à windows : un active directory et voilà)

    • Les logiciels évoluent sans tenir compte des besoins des utilisateurs lambda : Libreoffice sur mon mac (entre temps moi aussi j'ai craqué après 12 ans de fidélité) est d'une lenteur pour ouvrir un fichier excels de 125 lignes contenant beaucoups de texte (excel nickel), mais il peut théoriquement ouvrir des milliers de feuilles (qui le fait ?). L'ergonomie n'a pas beaucoup bougé, tandis que word complètement.

    On voit directement les secteurs qui sont soutenus par les entreprises. La totalité des serveurs sont sous linux et ça tourne nickel. Par contre combien de bureau et de distribution ? Combien d'énergie dépensée pour réinventer la roue alors qu'elle n'est même pas encore bien ronde.

    Désolé pour les fautes, je n'ai pas du tout l'habitude d'écrire hormis du code.

    Lire les commentaires

  • Migrer Windows 10 d'un disque BIOS/MBR, vers un SSD en mode UEFI/GPT avec des logiciels libres (Journaux LinuxFR)

    Sommaire

    Introduction

    Ce tutoriel vous guide pas à pas pour migrer votre installation de
    Windows qui est actuellement sur un disque dur de votre PC vers un
    nouveau disque, en l'occurrence un SSD. A vrai dire, vous pouvez aussi
    bien migrer vers un autre HDD.

    La spécificité de ce tutoriel est qu'elle utilise les outils fournis par
    Microsoft avec Windows ainsi que des logiciels libres (Clonezilla
    principalement, mais si quelque chose devait mal tourner vous pouvez avoir
    besoin d'utiliser fdisk, gdisk ou testdisk pour ne citer qu'eux). Quand
    j'ai voulu faire cette migration je n'ai pas trouvé de tutoriel
    expliquant de bout en bout comment faire cette migration juste avec les
    outils de Microsoft et des logiciels libres.

    Typiquement, vous pouvez avoir envie/besoin de faire cela car vous avez
    acheté un nouveau disque pour remplacer l'ancien (par exemple car
    l'ancien montre des signes de faiblesse, ou vous voulez améliorer la
    réactivité de votre système).

    En plus de la migration du système d'exploitation, ce tutoriel vous
    explique comment passer d'un démarrage en mode BIOS/MBR à un démarrage
    en mode UEFI/GPT.

    Succinctement la démarche est la suivante, d'abord installer le nouveau
    disque dans le PC, et initialiser la table de partition selon les normes
    Microsoft. Puis cloner/dupliquer la partition contenant le système
    d'exploitation à l'aide de Clonezilla. Ensuite et avant de redémarrer
    dans le clone de Windows sur le SSD, faire quelques modifications dans
    le registre pour que la lettre de lecteur C: pointe vers la bonne
    partition et éventuellement modifier le mode SATA en AHCI si vous le
    modifiez aussi dans le UEFI/BIOS. Après cela, on va préparer la
    partition système EFI/ESP pour que le PC puisse démarrer dessus et qu'il
    démarre sur le Windows du SSD. Finalement, une fois dans le Windows du
    SSD, on va réactiver l'"environnement de récupération de Windows".

    Mise en garde : Faites une sauvegarde de vos données avant toute
    opération. Personne n'est à l'abri d'une mauvaise manipulation ou d'une
    erreur.

    Prérequis

    Compétences

    Niveau de difficulté : Difficile.

    Vous devez être à l'aise au niveau de l'utilisation de la ligne de
    commande dans Windows, mais aussi assez à l'aise pour gérer les
    partitions de votre disque. Savoir modifier le paramétrage de votre
    Firmware UEFI/BIOS et aussi nécessaire. Ce tutoriel guide pas à pas pour
    la majorité des opérations. Certaines n'ont pas été détaillées par souci
    de simplicité et d'efficacité.

    Matériel

    Le PC où vous voulez installer le SSD. Il faut qu'il soit en état de
    marche. De plus il doit avoir un firmware UEFI. S'il n'a que un BIOS
    standard, sans UEFI, ce tutoriel n'est pas adapté.

    Clé(s) USB ou plusieurs CD/DVD sur lequel vous aurez mis
    Clonezilla, System rescue
    CD
    et un environnement de démarrage
    Windows PE, ou Windows RE, ou le DVD/Disque d'installation de Windows.

    Le disque SSD (testé avec Samsung SSD 860 EVO 250GB). Il doit avoir une
    taille suffisante pour contenir votre partition de Windows. Dans tous
    les cas, la taille de la partition qui contiendra Windows sur le SSD
    doit être au moins égale à la taille de la partition Windows du HDD que
    vous voulez cloner. Au besoin, pour remplir ce critère, réduisez la
    taille de votre partition Windows avec le gestionnaire de disque de
    Windows par exemple (ou un autre outil de gestion de partition, comme
    gparted, sur le System Rescue CD). Cherchez sur internet si vous ne
    savez pas comment faire.

    Logiciel

    Windows 10 installé (en version 64 bits) (testé avec Win10 v1709)

    Windows 10 PE ou support d'installation de Windows 10 (clé USB ou DVD) -
    En Version 64 bits (testé avec un support d'installation de Win10 v1804)

    System rescue CD (version 5.2.2 par
    exemple)

    Clonezilla installé sur une clé ou un CD.
    Bien vérifier avant que votre système arrive à démarrer dessus. (Testé
    avec Clonezilla 2.5.5-38)

    Nomenclature

    SSD : désigne le nouveau SSD

    HDD : désigne votre disque actuel, sur lequel est installé Windows

    WinPE : un environnement de démarrage Windows PE, ou Windows RE, ou le
    DVD/Disque d'installation de Windows. Il doit être sur un support
    amovible (USB, CD ou DVD)

    S: La lettre de lecteur affectée à la partition Système EFI qui sera sur
    le nouveau SSD (parfois appelée ESP, EFI_System_Partition ou encore
    SYSTEM, ou EFI)

    N: Le clone de Windows, sur le SSD

    O: Le Windows cloné, sur le HDD

    C: La partition dans laquelle est installée Windows, lorsqu'on est dans
    Windows (que ce soit le windows cloné, ou le clone)

    Les commandes doivent être lancées en tant qu'administrateur.

    Procédure de base

    • Fixer et brancher le SSD dans l’ordinateur

    • Désactiver Windows FastStart (cf votre moteur de recherche préféré)

    • Initialiser et partitionner le disque à l'aide de Windows

      • Démarrer sur le Windows installé ou WinPE
      • Pour initialiser le disque, d'abord créer une table de partition, puis partitionner le disque. Pour ce faire :
        • Suivre les instructions de partitionnement UEFI/GPT selon Microsoft. Ci-dessous mon exemple, mais peut-être avez-vous besoin d'une partition "recovery" aussi, ou votre configuration nécessite quelques aménagements. Dans ce cas, voir les instructions de Microsoft et adapter pour vos besoins.
        • Par exemple: une partition EFI de 260Mo, une partition Microsoft Reserved (MSR) de 16Mo, une partition pour Windows (taille au moins égale à la taille de la partition de Windows à cloner). Pour informations, dans diskpart, les tailles que vous donnez en MB/Mo sont en réalité des MiB/Mio (220 = 10242 octets).
          • Ouvrir une invite de commande en mode administrateur et lancer diskpart . Et une fois dans diskpart :
            • list disk pour lister les disques et connaître le n° du SSD.
            • select disk # avec le numéro du SSD à la place de #
            • clean Supprime le contenu du disque / l'initialise
            • convert gpt Définit que le disque aura une table de partition GPT
            • create partition efi size=260 Crée une partition EFI de 260MiB
            • format quick fs=fat32 label="System" Formater la partition EFI au format FAT32
            • assign letter="S" Lui donner la lettre S
            • create partition msr size=16 Créer une partition Microsoft Reserved de 16MiB
            • create partition primary Créer la partition pour Windows (l'équivalent du C: )
            • format quick fs=ntfs label="Windows" Formater la partition pour Windows au format NTFS
            • assign letter="N" Lui donner la lettre N
            • list volume Liste les volumes. Permet de voir la table de partition.
            • exit Quitte diskpart
    • Cloner le Windows installé sur le HDD. Ceci sera fait à l'aide de
      Clonezilla

      • Redémarrer dans Clonezilla
      • Une fois dans clonezilla, et si vous êtes confortable avec les lignes de commande Linux, éventuellement supprimer de la partition Windows du HDD les fichiers pagefile.sys , hyberfil.sys (désactiver windows faststart avant), swapfile.sys .
      • Cloner la partition Windows du HDD vers le SSD (de préférence, partition de même taille, et de toutes façons, la partition de destination doit être plus grande que la source. Si ce n'est pas le cas, réduisez d'abord la taille de votre partition Windows depuis Windows). Dans clonezilla, utiliser le mode Partition vers Partition, et en mode Export. Utiliser les options -e1 auto (automatically adjust file system geometry for a ntfs boot partition if exists) -e2 (sfdisk uses CHS of hard drive from EDD (for non grub loader) -r (resize filesystem to fit partition size of target) -m (do NOT clone boot loader) -v (verbose)
      • Optionnellement cacher la partition contenant le windows source de la table de partition du disque source (si vous ne savez pas à quoi ça sert, passez votre chemin). Pour cela modifier le type de partition de la partition NTFS de windows (en principe, NTFS a un id de « 7 ». On peut utiliser id 17 pour la partition cachée : 17 correspond à « IFS Hidden »). Utiliser cfdisk ou fdisk pour faire ce changement (ce sont des programmes linux).
    • Dans le Firmware UEFI (ou BIOS-UEFI), on peut en profiter pour passer
      du mode SATA "IDE" vers "AHCI". Windows n'aime pas ce changement et
      il faut donc faire une opération dans le registre qui est
      détaillée ci-dessous. Tant que vous ne le faites pas, vous aurez un
      écran de plantage bleu de windows au démarrage (BSOD).

    • Si vous voulez être sûr de ne pas faire de bêtise dans le Windows que
      vous venez de cloner, je vous conseille d'éteindre l’ordinateur & de
      débrancher l’ancien disque. Ainsi vous ne risquez pas de modifier le
      mauvais fichier de registre (en l'occurrence celui de votre Windows
      sur le HDD)

    • Effectuer quelques opérations sur le Windows de destination (celui
      sur le SSD) avant qu'on ne démarre dessus. En particulier corriger le
      registre pour affecter la lettre de lecteur C: à la bonne partition,
      et si le paramétrage du Firmware UEFI (BIOS-UEFI) a été modifié pour
      passer de SATA Mode PCI vers AHCI, on va aussi faire ce changement
      pour que ca fonctionne.

      • Redémarrer dans WinPE (en Mode UEFI, pas MBR !)
        • Tout d'abord déterminer la lettre de lecteur affectée au clone de Windows, celui qui est sur le SSD. Ou, s'il n'y a pas de lettre affectée, lui en donner une, par exemple N: (lettre utilisée dans les exemples qui suivent)
          • Pour cela, lancer dans diskpart
            • list volume
              Ce qui retourne la liste des volumes avec la lettre de lecteur qui a été affectée à chacun.
          • Si aucune lettre de lecteur n'est affectée, il faut alors lui en affecter une. Pour cela, lancer dans diskpart
            • select volume # (avec # étant le numéro du volume qui contient le nouveau windows)
            • assign letter=N
              S'il n'est pas possible d'utiliser select volume alors faire comme ceci
            • list disk
            • select disk # (# étant le numéro affecté au SSD)
            • list partition
            • select partition # (# étant le numéro affecté à la partition de Windows sur le SSD, probablement 3)
            • assign letter=N
        • Faire un CHKDSK /F sur la lettre du nouveau Win
        • Pour que la partition C: utilisée par Windows soit celle du SSD et pas celle de l’ancien disque, modifier une clé de registre du nouveau Windows :
          • Lancer REGEDIT et dans le registre HKEY_LOCAL_MACHINE monter la ruche N:\Windows\System32\Config\SYSTEM . Lui donner le nom "NewWin" On s’intéresse à HKEY_LOCAL_MACHINE\NewWin\MountedDevices . Ce sont là les valeurs qui sont dans le registre " HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices " lorsqu'on est dans l'installation de Windows.
            • Dans HKEY_LOCAL_MACHINE\NewWin\MountedDevices modifier la lettre de lecteur C: en renommant \DosDevices\C: par \DosDevices\O: (car la valeur fait référence à la partition de l'ancien Windows sur le HDD et on ne veut pas, en démarrant, utiliser cette partition mais celle de son clone qui est sur le SSD). Ainsi, lorsqu'on démarrera dans le nouveau Windows, la partition contenant le Windows sur le HDD aura la lettre O:, et la partition contenant le Windows sur le SSD aura la lettre C:
            • Créer une nouvelle valeur binaire nommée \DosDevices\C: et lui donner comme contenu celui de \DosDevices\N: qui est renseignée dans le registre WinPE, c'est-à-dire là HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices ( C: étant la lettre qu'utilisait le Windows du HDD comme partition où il y a le dossier \Windows )
            • ATTENTION: Bien vérifier que la copie a fonctionné et qu'il y a les bonnes valeurs, car dans mes essais, j'ai du m'y reprendre à 2 fois car le 1er "coller" ne collait pas ce que je voulais.
            • En principe c'est tout. Mais d'après certaines sources, il y aurait une clé \\?\Volume{GUID} ayant le même contenu que le \DosDevices\O: qu’on vient de modifier. Chez moi ce n'était pas le cas. Si vous avez une telle valeur, alors il faut lui donner le contenu de \DosDevices\N: depuis le registre WinPE
        • Si en même temps que la migration on veut aussi passer du mode SATA IDE vers AHCI alors il faut encore faire ceci. Cela a été repris du site tomshardware.co.uk
          • Toujours dans REGEDIT avec la ruche montée en HKEY_LOCAL_MACHINE\NewWin
          • Aller à HKEY_LOCAL_MACHINE\NewWin\ControlSet000\Services\storahci\StartOverride
          • Changer la valeur DWORD de 3 à 0.
          • Au redémarrage, si ça n'a pas été fait, changer la paramétrage du contrôleur SATA de IDE à AHCI. Au redémarrage, Windows devrait directement démarrer correctement et sans plantage (BSOD).
        • Rendre le disque bootable en installant les outils EFI de microsoft et configurant le Magasin BCD (BCD Store)
          • D'abord assigner une lettre de lecteur à la partition ESP
            • MOUNTVOL S: /S
              Si ca n'a pas fonctionné, faire comme ceci dans diskpart
            • list disk
            • select disk # (# est le numero du SSD retourné par list disk)
            • list partition
            • select partition # (# est probablement 1)
            • assign letter=S
          • Puis lancer bcdboot N:\windows /l fr-fr /s S: /f UEFI
            • N:\Windows est le répertoire contenant le clone de Windows sur le SSD)
            • S: = partition EFI
    • Redémarrer, et avant le lancement de Windows vérifier votre UEFI
      (ou BIOS-UEFI). Il faut qu'il soit configuré pour démarrer par défaut
      en mode UEFI et pas en mode BIOS. Penser aussi à corriger le
      paramétrage SATA si cela a été modifié dans le registre de Windows.

      Le paramétrage du démarrage avec
      bcdboot N:\windows /l fr-fr /s S: /f UEFI a normalement créé le
      magasin BCD, mis tous les fichiers EFI sur la partition SYSTEME (ESP,
      partiton EFI, la 1ère du SSD) et dit au firmware UEFI qu'il doit
      automatiquement démarrer avec le gestionnaire de démarrage
      (boot manager) de Windows.

    • Une fois qu’on a réussi à démarrer dans la copie de Windows

      • Réactiver le "FastBoot"
      • Réactiver l'environnement de récupération de Windows en lançant, depuis une ligne de commande avec les droits administrateur, la commande reagentc.exe /enable . Vérifier avec reagentc.exe /info . Et s'il y a une erreur essayer avec reagentc.exe /enable /setreimage /path C:\Recovery\WindowsREC:\Recovery\WindowsRE est le dossier où se trouve le fichier Winre.wim
      • Vérifier que tout est en ordre. Eventuellement donner un nouveau nom à votre partition C: (pour la différencier de celle sur le HDD) en lançant: LABEL [drive:][label]
      • Redémarrer encore une fois en laissant le processus de démarrage se faire tout seul pour vérifier que tout est ok.
    • Réinsérer l'ancien disque dur.

    • Normalement, il devrait être possible de redémarrer dans l'ancien
      Windows, du moment que vous savez comment booter en MBR, et sous
      réserve de ne pas avoir modifié le mode SATA dans le UEFI/BIOS. SI
      c'est le cas, vous pouvez envisager de modifier le registre du
      Windows du HDD, ou de modifier le paramétrage du UEFI/BIOS.

      Si vous avez aussi Linux d'installé sur le HDD, il devrait toujours
      être possible de le démarrer en mode BIOS

    • On peut diminuer/augmenter la taille de la partition C: du SSD (Pour
      un SSD TLC ou VNAND, on peut par exemple laisser de l’espace libre à
      la fin ~10 % de la capacité du disque d'après le logiciel Samsung
      Magician, pour un SSD 860 EVO)

    • En principe, puisqu’on boot en EFI on peut enlever sur le clone
      Windows sur le SSD les fichiers \bootmgr et \Boot\BCD puisque ce
      sont ceux qui étaient utilisés pour un boot en mode BIOS/MBR et que
      désormais on est en EFI. Vous pouvez d'abord les renommer et vérifier
      que ca ne change rien au prochain boot, plutôt que de les supprimer
      tout de suite.

    Quelques pistes si ça ne fonctionne pas…

    • Faire un chkdsk sur la nouvelle partition
    • Recréer le bootsector du NTFS avec testdisk (dispo sur System Rescue CD, mais peut être aussi dans Clonezilla ? Je n'ai pas vérifié)
    • Vérifier le BCD:
    • Vérifier que la partition EFI est bien initialisée (présence des fichiers \EFI , \EFI\Boot\ , \EFI\Microsoft\ …) Si ce n'est pas le cas, il y a eu un problème avec bcdboot N:\windows /l fr-fr /s S: /f UEFI
    • Vérifier le boot manager du bios (démarrage en UEFI ou MBR ? Gestionnaire de démarrage par défaut ? Présence du gestionnaire de démarrage de Windows ?)
    • A priori, pas utile : Commandes à lancer dans WinPE
      • Pour recréer le boot sector de la partition systeme (EFI): bootrec /fixboot
      • Pour chercher les OS sur le disque et les mettre dans le bootloader bootrec /scanos
    • Quelques commandes de bcdedit pour modiser la valeur de certains éléments du magasin BCD. Inutile car le BCD Store qui est utilisé lorsqu'on démarre en mode EFI n'est pas le même que celui utilisé dans un démarrage en mode MBR. Donc, pas besoin de chercher à modifier le BCD. Je garde pour info : les lettres sont celles telles que définies dans le système où on est (WinPE par ex). Doc BCDEDIT
      • bcdedit /set {bootmgr} device \Device\HarddiskVolume1
      • bcdedit /set {default} device \Device\HarddiskVolume3
      • bcdedit /set {default} osdevice \Device\HarddiskVolume3
      • Ou à la place de \Device\HarddiskVolume1 mettre les lettres de lecteur :
      • bcdedit /set {bootmgr} device partition=S:
      • bcdedit /set {default} device partition=C:
      • bcdedit /set {default} osdevice partition=C:

    Documentation, pour aller plus loin…

    A propos du EFI/UEFI:

    A propos de l'entrée MountedDevices du registre:
    http://diddy.boot-land.net/firadisk/files/mounteddevices.htm

    Si on veut y accéder, par défaut les fichiers du BCD sont cachés. Pour
    les rendre visibles:

    • attrib bcd -s -h -r
    • mv bcd bcd.bak
    • bootrec /rebuildbcd

    Documentation bcdedit:

    MBR Partition ID

    A propos des disk ID (=Disk signatures):

    Si besoin de supprimer du registre les entrées de disques qui ne sont
    pas connectés ou sans lettre assignée lancer: mountvol /R. Ce
    programme permet aussi de lister les lettres de volumes avec leur GUID
    (GUID pour ce système uniquement, il n’est pas stocké dans la partition,
    ni ailleurs sur le disque, il est assigné par windows pour un couple
    (signature de disque/partition offset) dans une instance de windows
    alors que dans une autre instance de windows la même partition sur le
    même disque aura ce GUID différent)

    Changer le label du volume: commande LABEL [drive:][label]

    Historique de révisions

    • Vous trouverez la dernière version de ce tutoriel sur ma page perso
      de tutoriels informatique
      .
      Vous y trouverez aussi la version HTML, PDF et TXT.

    • 2018-06-17 : Ajout d'une note indiquant que ce tutoriel utilise des
      logiciels libres

    • 2018-06-11 : Correction de la forme et de fautes d'orthographe

    • 2018-05-28

    Commentaires : voir le flux atom ouvrir dans le navigateur

  • AlterncCamp c'est dès jeudi 21 juin (Journaux LinuxFR)

    Salut

    Ayant déjà fait la dépéche et que le temps est passé, j'en profite pour rappeler que jeudi, vendredi et samedi il est possible d'aider à l'avancée du projet alternc

    Commentaires : voir le flux atom ouvrir dans le navigateur

  • Un petit tour des systèmes de build (Journaux LinuxFR)

    Sommaire

    Parlons un peu de systèmes de build.

    Mon métier consiste à programmer des jeux vidéos destinés aux plates-formes mobiles Android et iOS. Ce qui est commun aux deux plates-formes, c’est-à-dire la plus grosse partie de l'application, est écrit en C++, et ce qui est spécifique à la plate-forme est en Java ou en Objective-C. L'intérêt principal de tout faire en C++ est que les développeurs peuvent lancer l'application directement sur leur poste de travail, sous Linux ou OSX, et tester leurs modifs sans payer le prix d'un émulateur ou du transfert sur un appareil mobile.

    L'inconvénient est que l'on se retrouve à gérer des builds sur quatre plates-formes.

    Pour compiler une application pour iOS il faut nécessairement un projet Xcode, bien que les bibliothèques puissent être compilées classiquement en ligne de commande. Cela signifie qu'il faut maintenir un fichier de projet Xcode ou alors avoir un outil pour le générer.

    Côté Android la compilation du code C++ se fait avec l'outil ndk-build, qui est en réalité une interface à GNU Make. Du coup les fichiers de projet sont évidemment des makefiles mais utilisant des variables et fonctions d'une sorte de framework dans le langage de Make. Là encore il faut maintenir des makefiles pour le projet, ou avoir un outil pour les générer.

    Pour Linux et OSX la compilation peut se faire avec des outils plus classiques mais évidemment pas avec les fichiers de build iOS ou Android. Et encore une fois il faut maintenir ces fichiers de build.

    À moins qu'on ait un outil pour les générer tous…

    Quelques systèmes de build

    Le problème de la gestion de la compilation d'un projet a été posé bien avant ta naissance ; c'est pour cela qu'il n'existe qu'une seule méthode pour le faire, qui fait consensus depuis des décennies.

    Ha ! Ha ! Ha !

    Je peux te citer déjà douze outils de tête. Voyons un peu la présentation faite sur leurs sites respectifs et essayons de rester de bonne foi.

    Make

    D'après le site :

    GNU Make est un outil qui contrôle la génération d'exécutables et autres fichiers non-source d'un programme à partir des fichiers source du programme.

    J'ai mis la description du site de GNU Make mais la première version de Make date d'avril 1976. Elle précède ainsi le projet GNU de sept ans.

    Le principe de base de Make est assez simple, on lui passe un fichier Makefile qui indique « voilà le fichier que je veux créer, il dépend de ces autres fichiers, et voilà les commandes à exécuter pour le créer ». Avec le mécanisme des dépendances l'outil se débrouille pour créer les cibles dans l'ordre.

    Il m'arrive encore de créer des petits Makefiles manuellement mais c'est vite pénible. Par exemple, si un binaire app est créé à partir d'un fichier a.cpp qui inclut un fichier b.hpp qui inclut lui-même un fichier c.hpp, en toute rigueur je dois lister ces trois fichiers en dépendances de la cible app pour que la compilation soit refaite quand l'un d'eux est modifié. On fait ça une fois puis on cherche un truc pour que les dépendances soient gérées automatiquement.

    Un autre point difficile à gérer concerne la dépendance au fichier Makefile lui-même. Par exemple, si j'ajoute une option qui concerne l'édition des liens, celle-ci ne sera pas refaite par défaut.

    Autotools

    [Le premier objectif des Autotools] est de simplifier le développement de programmes portables. Le système permet au développeur de se concentrer sur l'écriture du programme, simplifiant de nombreux détails de portabilité entre systèmes Unix et même Windows, et permettant au développeur de décrire comment construire le programme via des règles simples plutôt que des Makefiles complexes.

    Si vous avez déjà utilisé les autotools vous êtes probablement morts de rire en lisant ce paragraphe. Cette suite d'outils qui se présente comme simple et portable est en réalité ce qu'il y a de plus complexe en système de build et n'est portable que sur les systèmes Unix en évitant soigneusement Windows, le plus déployé des systèmes des trente dernières années.

    Sans doute révolutionnaire à sa création, cet outil a extrêmement mal vieillit. Pour ma part j'ai eu l'occasion de compiler des logiciels tiers sous Windows avec ça et c'était tout simplement l'enfer. J'ai aussi tenté de l'utiliser pour mes propres projets et je me suis arrêté dans le tuto. Depuis je suis convaincu que ces outils sont faits pour les développeurs qui aiment transpirer.

    SCons

    SCons est un outil Open Source de construction de logiciel—plus précisément, une nouvelle génération d'outil de construction. Voyez SCons comme un substitut amélioré et multi-plateforme pour l'utilitaire Make classique avec des fonctionnalités intégrées similaires à autoconf/automake et aux caches de compilation tels que ccache. Pour faire court, SCons est un moyen plus facile, plus fiable et plus rapide de construire un logiciel.

    Wow, là c'est carrément le futur.

    Les fichiers SCons s'écrivent directement en Python, ce qui est assez sympa puisqu'on se retrouve avec un vrai langage et un a accès à un tas de bibliothèques pour décrire le projet.

    J'ai compilé quelques projets en SCons il y a une quinzaine d'années et je crois que je n'ai jamais rien vu d'aussi lent. Et pas seulement parce que c'est du Python…

    Il faut dire que le comportement par défaut de l'outil est de détecter les modifications des fichiers sources en calculant un md5 des fichiers, pour éviter de recompiler des fichiers dont seule la date a changé. Quand on voit le prix d'un md5 je trouve ce choix très discutable. Ce comportement peut être modifié via une option mais même en passant sur une comparaison de timestamps et en appliquant toutes les astuces connues pour le rendre plus rapide, ça reste hyper lent.

    Premake

    Un système de configuration de construction puissamment simple
    Décrivez votre logiciel qu'une seule fois, via la syntaxe simple et facile à lire de Premake, et construisez-le partout.
    Générez des fichiers de projets pour Visual Studio, GNU Make, Xcode, Code::Blocks, et plus sous Windows, Mac OS X et Linux. Utilisez l'intégralité du moteur de script Lua pour que la configuration de la construction devienne du gâteau.

    Pfiou, ça claque ! Ce n'est que le quatrième dans la liste et ça promet déjà de tout résoudre

    Avec Premake les scripts de builds sont écrits en Lua et, à l'instar de SCons, cela permet de « programmer » son build en profitant de tout un tas de bibliothèques.

    Sur le papier c'est très sympa, en pratique ça ne marche pas trop comme attendu. Il s'avère que la syntaxe de Premake est déclarative et ne se mélange pas bien avec le procédural de Lua. Par exemple, si j'écris

    project "P"
    
    if false then
        files
        {
          "file.cpp"
        }
    end
    

    On pourrait croire que le fichier file.cpp ne fera pas partie du projet P, et bien pas du tout, le if ne change rien du tout ici. Difficile de programmer dans ces conditions.

    Nous utilisons Premake depuis presque quatre ans au boulot. Le choix s'est fait en sa faveur bien que l'outil était en alpha car il permettait de générer des fichiers pour Xcode et ndk-build via deux plugins indépendants, en plus des Makefiles classiques. Aussi, il avait l'air facile à hacker ce qui était rassurant.

    Maintenant j'essaye de le remplacer autant que possible.

    Parmi les problèmes récurrents le plus pénible est certainement le message error: (null), sans autre info, que l'outil affiche parce qu'une erreur s'est glissée dans un script. Bonne chance pour déboguer ça. J'aime aussi beaucoup le message Type 'premake5 --help' for help qui s'affiche quand je fais une faute de frappe sur la ligne de commande. Là encore il n'y a aucune information utile et il faut se débrouiller pour trouver où on s'est trompé. Autre souci : il n'y a pas moyen de mettre des propriétés de link spécifiques à une bibliothèque. C'est embêtant quand on a besoin d'un -Wl,--whole-archive.

    Le développement de Premake en lui-même a l'air très laborieux. Quatre ans après il est toujours en alpha, avec une release datant d'août 2017. Le module Xcode a été intégré mais ne gère que OSX. Il a fallu réappliquer toutes nos modifs pour iOS. Quant au module pour le NDK il ne fonctionne plus suite à des changements dans Premake (hey, c'est une alpha…). Là encore il a fallu repatcher.

    Il y a de nombreux contributeurs, dont des gros, mais chacun a l'air d'aller dans sa propre direction sans qu'il y ait d'objectif commun. Il y a par exemple deux générateurs de Makefiles, gmake et gmake2 (j'attends impatiemment yagmake). Il y a des fonctionnalités qui ne marchent qu'avec Visual Studio, d'autres trucs qui fonctionnaient il y a quatre ans et qui ne fonctionnent plus. Ça m'a l'air d'être typiquement le projet qui veut tout faire parfaitement et qui au final ne fait rien de bien. Bref, le produit n'est pas à la hauteur du pitch.

    CMake

    CMake est une suite d'outils open source et multi-plateforme conçus pour construire, tester et empaqueter des logiciels. CMake est utilisé pour contrôler le processus de compilation du logiciel via des fichiers de configuration indépendants du compilateur et de la plate-forme, et il génère des fichiers Makefiles natifs ou des projets qui peuvent être utilisé avec l'environnement de compilation de votre choix.

    CMake est tout simplement mon outil de build préféré de ces quinze dernières années.

    Tout est dit.

    Bon OK, j'explique. CMake lit des fichiers CMakeLists.txt qui décrivent les projets à compiler dans un langage qui lui est propre. À partir de cela il génère des fichiers Makefile ou autres (des projets Xcode ou Visual Studio par exemple) qui permettent de construire le projet.

    Ce qui m'a convaincu dans cet outil est qu'il est plutôt rapide (bien qu'il ne soit pas le plus rapide) et qu'il gère parfaitement les règles de reconstruction des cibles. Par exemple, si j'ajoute un paramètre de ligne de commande pour l'édition des liens, alors l'édition des liens va être refaite. Si je modifie un fichier CMakeLists.txt et que j'exécute make sans relancer CMake, alors CMake se relance tout seul (les Makefiles ont une règle de dépendance vers les CMakeLists.txt, pas con!) Je peux aussi simplement définir les répertoires d'entêtes, options de compilation et autres paramètres spécifiques à chaque projet, en précisant s'il le paramètre doit être visible des projets dépendants ou non.

    L'outil est assez bien fichu et est très populaire dans le milieu du C++.

    Un des points les plus souvent reprochés à CMake est son langage, notamment à l'époque de la version 2 de l'outil qui était excessivement verbeuse et en plus en ALL CAPS. On avait l'impression de se faire crier dessus à longueur de fichier. Aujourd'hui ces soucis sont résolus et le problème semble surtout être que cela fait un langage de plus à apprendre et qui ne sert à rien d'autre (contrairement à SCons et Premake par exemple). Perso je n'y vois pas de difficulté, c'est un bête langage à macros avec des mécanismes bien pratique pour nommer des groupes de paramètres.

    Comme d'habitude la qualification « indépendants du compilateur et de la plate-forme » des fichiers de configuration est très discutable dans la mesure où il y a tout ce qu'il faut pour glisser des commandes système dans le build.

    Les principaux problèmes que j'ai pu rencontrer avec une version récente de CMake concernent l'export de projet. En effet il y a une commande install(EXPORTS) qui permet de créer un fichier de configuration CMake pour inclure la cible en tant que dépendance dans un projet tiers. Malheureusement cette commande exporte par défaut les chemins absolus des dépendances de la cible et il faut bricoler pour exporter les dépendances proprement (en les enrobant dans des cibles importées par exemple).

    Un autre souci est que CMake génère plein de fichiers intermédiaires et qu'avec la pratique généralisée de lancer le build à la racine du projet on se retrouve à polluer toute l'arborescence. Idéalement il faudrait que l'outil refuse de faire un build in-source.

    Ninja

    Ninja est un petit système de construction se concentrant sur la vitesse. Il est différent des autres systèmes de construction sur deux aspects majeurs : il est conçu pour que ses fichiers d'entrées soient générés par un système de construction de plus haut niveau, et il est aussi conçu pour exécuter les builds le plus rapidement possible.

    Ah cool, encore un outil qui se veut rapide, c'est exactement ce qu'il nous manquait. En plus quand on voit SCons et Premake qui se prétendent déjà les plus rapides, on a tout de suite confiance. Cela dit, contrairement à SCons et Premake, Ninja n'est pas un générateur de script de build. Il serait plutôt à comparer à Make.

    Je n'ai jamais utilisé Ninja mais si jamais mes builds devenaient très lents je n'hésiterais pas à y jeter un coup d'œil. À moins que je ne passe à Meson.

    Meson

    Meson est un système open source de construction voulant être à la fois extrêmement rapide et, encore plus important, aussi accessible que possible.

    Bon là je désespère. Encore un outil qui veut être le plus rapide et toujours pas d'outil qui prétend fonctionner correctement.

    Je n'ai jamais utilisé Meson mais on m'a dit que c'est-nouveau-c'est-bien-tu-devrais-essayer.

    Pourquoi pas, enfin moi je cherche surtout un truc qui me génère de quoi faire un build iOS, Android, OSX et Linux. Un truc qui juste marche quoi.

    FASTbuild

    FASTBuild est un système de construction open source et de haute performance supportant une haute montée en charge de la compilation, la mise en cache et la distribution sur le réseau.

    Non mais franchement…

    Là encore je n'ai pas utilisé cet outil. La promesse est sympa mais je ne vois pas trop l'intérêt par rapport aux deux mille autres outils du même genre.

    Sharpmake

    Sharpmake est un générateur de projets et solutions pour Visual Studio. Il est similaire à CMake et Premake, mais il est conçu pour être rapide et passer à l'échelle.

    Celui-ci est développé par Ubisoft initialement en interne et libéré en septembre 2017. Apparemment il n'y a plus d'activité dans le dépôt depuis octobre de la même année. Comme son nom l'indique, les scripts de build sont écrits en C#.

    D'après la doc il sait aussi générer des projets pour Xcode et des Makefiles. J'ai longtemps considéré l'utiliser en remplaçant de Premake mais d'une part c'est écrit en C#, donc c'est mort pour l'utiliser sous Linux, et d'autre part je sens bien que tout ce qui n'est pas Windows et Visual Studio va être bancal.

    Maven

    Apache Maven un outil de compréhension et de gestion de projet logiciel. Basé sur le concept de modèle d'objet de projet, Maven peut gérer la construction, le compte-rendu et la documentation d'un projet depuis un élément central d'information.

    Je ne sais pas vous mais moi je comprends à peine le descriptif. C'est peut-être ma traduction qui est foireuse.

    Maven est un outil du monde Java. J'ai pu l'utiliser un peu via des scripts déjà prêts et il n'y a pas grand-chose à lui reprocher de ce point de vue. Ça m'a l'air assez cool pour la gestion des dépendances.

    C'est un outil qui a l'air très professionnel. Ah mais attend… c'est pour ça qu'on comprend rien au descriptif ! La première version date de 2004 et c'est donc tout naturellement que le langage le plus populaire du début du siècle a été choisi pour les scripts de build, je parle bien sûr du 🎉 XML 🎉.

    Ant

    Apache Ant est une bibliothèque Java et un outil en ligne de commande dons la mission est de piloter des processus décrits dans des fichiers de construction en tant que cibles et points d'extensions dépendant les uns des autres.

    Là encore ça sent le professionnalisme. Les fichiers Ant sont des sortes de Makefiles mais écrits en XML. Faut-il le préciser, Ant est lui aussi un outil du monde Java.

    Gradle

    Accélérez la productivité des développeurs
    Depuis les applications mobiles aux micro-services, des petites startups aux grandes entreprises, Gradle aide les équipes à construire, automatiser et livrer de meilleurs logiciels, plus rapidement.

    Je te laisse deviner à quel langage est destiné cet outil.

    Gradle est l'outil de référence pour les builds des applications Android et c'est donc dans ce cadre que j'ai pu l'utiliser. Les scripts Gradle sont écrits en Groovy, un langage que je n'ai jamais utilisé par ailleurs. Perso je trouve pas ça génial mais c'est peut-être simplement parce ce que c'est loin de ce que l'on fait en C++.

    Les trucs qui me fatiguent le plus avec Gradle sont d'abord le temps de compilation. La compilation du projet Java de nos jeux, une partie qui contient pourtant peu de code, prend quasiment une minute. L'autre souci est de trouver de la doc claire et facile à digérer. La doc officielle représente à peu près 24% du web[référence nécessaire], ce qui fait que la moindre interrogation demande déjà plusieurs heures de lectures, et les exemples de StackOverflow et divers blogs sont assez disparates.

    Que choisir

    Déjà douze outils et rien n'a l'air de dominer le marché :/ Sans doute faudrait-il inventer un nouvel outil pour les remplacer tous, quelque chose d'hyper rapide, évolutif, mais aussi adapté aux processes de déploiement intraprocéduraux sur concentrateur décentralisés pour les plus professionnels d'entre nous, avec des scripts dans un langage populaire, type GOTO++.

    Malgré tout ce choix je n'ai rien trouvé qui résolve mon problème : générer un projet pour iOS, Android, Linux et OSX avec un seul script. Si vous avez une idée, ça m'intéresse.

    Commentaires : voir le flux atom ouvrir dans le navigateur

  • Agenda du Libre pour la semaine 26 de l'année 2018 (Dépêches LinuxFR)

    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 30 événements (1 en Belgique, 29 en France, 0 au Luxembourg, 0 au Québec 0 en Suisse et 0 en Tunisie) est en seconde partie de dépêche.

    Sommaire

    [FR Nantes] Cycle café vie privée Protection de son trafic sur Internet (VPN) - Le lundi 25 juin 2018 de 18h00 à 21h00.

    Protection de son trafic sur Internet

    Pourquoi et comment chiffrer son trafic sur Internet avec un VPN (réseau privé virtuel) ?
    Présentation du fonctionnement d’un VPN, de son intérêt et de sa mise en place.

    Au bar associatif La Dérive https://lajavadesbonsenfantsblog.wordpress.com/

    [FR Grenoble] Contribuer à BANO, la base d’adresse nationale d’OSM - Le lundi 25 juin 2018 de 18h30 à 20h30.

    Le collectif OpenStreetMap Grenoble vous invite à son prochain atelier OSM, La Base Adresses Nationale Ouverte (BANO) est une initiative d’OpenStreetMap France.

    Elle a pour objet la constitution d’une base la plus complète possible de points d’adresse à l’échelle de la France.

    L’objectif est de proposer une couverture d’adresses la plus étendue possible et la plus homogène possible.

    Cela doit permettre de réaliser sur le plus largement possible des opérations de géocodage (Quelle position correspond à cette adresse) et de géocodage inversé (Quelle adresse correspond à cette position).

    Lors de ce mapathon, le collectif OpenStreetMap Grenoble vous propose d’apprendre à contribuer à la BANO.  

    À partir de 18h30 à La Coop-Infolab. 31 rue Gustave Eiffel – 38 000 Grenoble

    BANO ou BAN

    La BAN (Base Adresse Nationale) est la base de référence nationale issue d’une convention signée entre l’IGN, le Groupe La Poste, l’État et OpenStreetMap France.

    BANO est un projet initié par OpenStreetMap France début 2014 et n’a pas encore intégré de données issues de la BAN (chantier en cours). Le contenu de la BAN est plus complet (plus de 20 millions d’adresses) que BANO (15. 5M d’adresses), mais n’intègre(ra) pas de contributions faites sur OpenStreetMap et encore très peu de données opendata diffusées par certaines collectivités.

    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

    [FR Gaillac] Atelier informatique libre - Le lundi 25 juin 2018 de 19h30 à 23h00.

    Un atelier d’informatique libre voit le jour au sein du chinabulle, pour créer un espace temps d’échange autour des solutions informatiques libres.

    [FR Marseille] PGDay France - Le mardi 26 juin 2018 de 08h30 à 17h30.

    Le PGDay France est un moment de rencontres et de conférences pour la communauté francophone de PostgreSQL.

    Les conférences s’adressent à tous les utilisateurs du logiciel étudiants, administrateurs systèmes, DBA, développeurs, chefs de Projets, décideurs.

    [FR Aiglun] Après-midi « Open data » et « Cartopartie » - Fête de l'été - Le mardi 26 juin 2018 de 15h00 à 19h00.

    Démarche participative et collaborative, il s’agit notamment de permettre aux associations, producteurs locaux, habitants et usagers de cartographier les services / activités qui constituent la richesse de notre territoire sur un outil libre (Openstreetmap).

    Les données publiques communales mises en ligne et la création d’un agenda partagé (à destination des associations) seront également valorisées.

    Les organisateurs du marché d’Aiglun proposeront de nombreuses animations à travers la fête l’été. Venez nombreux

    Tout l’après-midi marché bio et des producteurs locaux, animation musicale, balades avec les ânes, jeux, atelier de cartographie libre

    À 15 h, 16 h et 17 h visite du champ de lavande rendez-vous sur la place du marché

    À partir de 17 h dégustations des produits du marché préparés par le restaurant Le Pressoir Gourmand et grillades d’agneau

    À 18 h apéritif local offert par la mairie d’Aiglun, débat sur la cartographie et les données ouvertes

    [FR Quetigny] Découvrir, tester, installer Linux et d’autres logiciels libres - Le mardi 26 juin 2018 de 20h30 à 23h30.

    COAGUL est une association d’utilisateurs de logiciels libres et de GNU Linux en particulier.

    Nous utilisons toutes sortes de distributions GNU / Linux (Ubuntu, CentOs, Fedora, Debian, Arch…) et toutes sortes de logiciels pourvu qu’ils soient libres (VLC, LibreOffice, Firefox, Thunderbird, GPG, Tor, OpenNebula, LXC, Apache…).

    Nous partageons volontiers nos connaissances des logiciels libres et l’entraide est de mise dans nos réunions.

    Les permanences servent à se rencontrer et à partager nos expériences et notre savoir sur le logiciel libre.

    Vous souhaitez nous rencontrer nous vous accueillerons à notre permanence.

    On adore les gâteaux et les chocolats, vous pouvez donc en apporter-)

    [FR Le Mans] Permanence du mercredi après-midi - Le mercredi 27 juin 2018 de 12h00 à 17h00.

    Assistance technique et démonstration concernant les logiciels libres.

    [FR Rennes] Sécuriser son infrastructure - Le mercredi 27 juin 2018 de 18h30 à 21h00.

    La sécurité informatique ne repose pas que sur la qualité du code et le chiffrement (même s’ils sont essentiels), c’est aussi une question d’architecture.

    Vous (re)découvrirez quelques principes de sécurisation des infrastructures informatiques tels que la séparation des flux, la redondance et d’autres éléments pouvant améliorer la protection et la disponibilité des services.

    La conférence sera présentée par
      Thomas MICHEL
      Esprit Libre
      esprit-libre-conseil.com (link is external)

    mercredi 27 juin - 18h30

    FrenchTech Rennes - Saint-Malo
    2 rue de la Mabilais
    Rennes

    >>> S’inscrire

    [FR Montpellier] Rencontres des Groupes OpenStreetMap OSM - Le mercredi 27 juin 2018 de 19h00 à 22h00.

    Ces rencontres mensuelles se veulent être des instants conviviaux pour faire un compte-rendu des activités du mois précédent, mais aussi pour présenter les opérations et rendez-vous à venir que proposent les groupes HérOSM et le Collectif des Garrigues. Naturellement, elles sont également ouvertes à tout public.

    Si vous avez des propositions n’hésitez pas à compléter la page dédiée.

    Proposition de programme

    • En première partie de soirée, une initiation pour les débutants est prévue
    • Possibilité d’initiation à la contribution pour les débutants qui le désire
    • Préparation du dossier pour le budget de l’Opération Libre
    • Préparation de l’Opération Libre à Jacou
    • Travail sur les voies manquantes sur (enjeu évident de géocodage d’adresses, comme celles fournies par SIRENE ou FANTOIR par exemple
    • Petit topo sur la saisie des noms de rues à partir des données cadastre/fantoir par département
    • Propositions au sujet du calcul d’itinéraire multimodal (auto, vélo, piéton) dans les futures discussions

      • La pratique des cartoparties
      • Faut-il prioriser la cartographie de certains endroits (gares et arrêts de tram, par exemple) ?
    • Contributions libres

    Déroulement de la rencontre

    Nous vous présenterons les projets en cours, nous vous vous proposerons de contribuer, faire de la production de données, puis nous passerons à un instant convivial sur la terrasse.
    Comme d’habitude, chacun amène ce qu’il veut à manger et à boire pour un repas partagé.
    N’oubliez pas vos ordinateurs portables pour la séance de saisie

    Le dernier mercredi de chaque mois
    Mercredi 27 septembre 2017 de 19h00 à 22h00
    Mercredi 25 octobre 2017 de 19h00 à 22h00
    Mercredi 29 novembre 2017 de 19h00 à 22h00
    Mercredi 20 décembre 2017 de 19h00 à 22h00
    Mercredi 24 janvier 2018 de 19h00 à 22h00
    Mercredi 28 février 2018 de 19h00 à 22h00
    Mercredi 28 mars 2018 de 19h00 à 22h00
    Mercredi 25 avril 2018 de 19h00 à 22h00
    Mercredi 30 mai 2018 de 19h00 à 22h00
    Mercredi 27 juin 2018 de 19h00 à 22h00

    Mercredi 27 septembre 2017 de 19h00 à 22h00
    Le Faubourg - 15, rue du Faubourg de Nîmes, 34 000 Montpellier

    Tramway lignes 1, 2 et 4 arrêt Corum
    GPS Latitude 43.614186 | Longitude 3.881404
    Carte OpenStreetMap

    Le dernier mercredi de chaque mois.

    [FR Toulouse] Rencontres Tetalab - Le mercredi 27 juin 2018 de 20h30 à 23h30.

    Rencontre hebdomadaire des hackers et artistes libristes Toulousains.

    Ouvert au public tous les mercredi soir.

    Venez nombreux.

    [FR Choisy-le-Roi] Pas Sage en Seine - Du jeudi 28 juin 2018 à 10h00 au dimanche 1 juillet 2018 à 20h00.

    Le festival auto-organisé par vous et l’équipe de Pas Sage En Seine se tiendra du 28 juin au 1er juillet 2017 à Choisy-le-Roi dans et aux abords de la Médiathèque Louis Aragon.

    Nous vous invitons à participer à PSES2018 et venir participer à ses ateliers et conférences bien sûr, mais aussi installations, discussions et autres formes d’interventions.

    Des thèmes sont proposés, pas imposés, pour laisser place à la manifestation d’idées originales.

    Le Festival sera un moment convivial et festif pour décrire nos modes d’organisation, nos outils, nos perspectives, évoquer les usages d’autodéfense numériques faces aux perpétuelles manipulations sécuritaires.

    Le vendredi sera une journée spéciale consacrée au RGPD, et le samedi soir (lors de la micro-nocturne jusqu’à 21h30) vous pourrez assister à un concert de chiptune réalisé par le collectif Chip Bangers.

    L’Hacktiviste naît de cette prise de conscience intégrale. Il ouvre, détourne, invente tous les possibles, ou presque… Être et faire politiquement ensemble sera notre prochaine étape

    Le trajet depuis le centre de Paris prend une petite vingtaine de minutes uniquement (Gare du RER C Choisy-le-Roi).

    [FR Rennes] Conseil d’administration de Gulliver - Le jeudi 28 juin 2018 de 12h00 à 14h00.

    Gulliver tiendra son conseil d’administration à la Maison de la Consommation et de l’Environnement (MCE) le jeudi 28 juin 2018 à partir de 12 h. L’ordre du jour est donné dans le lien ci-dessous.

    Ce conseil d’administration est ouvert à tous. Toute personne, membre ou non membre de Gulliver, peut y assister (sauf CA exceptionnel signalé à l’avance), voir comment fonctionne notre association et y donner son avis.

    La MCE est située 42 bd Magenta à Rennes (plan d’accès). La salle réservée est celle de l’accueil.

    [FR Martigues] Permanence du jeudi de l'ULLM - Le jeudi 28 juin 2018 de 16h30 à 18h30.

    Comment utiliser et les Logiciels Libres.

    avec l’association des Utilisateurs de Logiciels Libres du Pays de Martégal (ULLM).

    28 2018 de 16h30 à 18h30 à la (quai des Anglais).

    Entrée Libre. Tout public.

    [FR Challans] Permanence Linux - Le jeudi 28 juin 2018 de 18h00 à 20h00.

    Chaque dernier jeudi du mois, Linux Challans vous donne rendez-vous à l’Albanera Café, 17 rue du Général Leclerc 85 300 Challans.

    Nous vous proposons lors de ces rendez-vous mensuels d’échanger autour du Libre, des conseils ou une assistance technique.

    Vous pouvez venir pour vous faire aider, ou aider, à installer et paramétrer une distribution GNU/Linux de votre choix ou des logiciels libres sur votre ordinateur.

    Recommandations

    • Sauvegardez vos données avant de venir.
    • Libérez de la place sur le disque dur (20 Go minimum) et défragmentez Windows si vous voulez le conserver.
    • Nous prévenir de votre passage via la messagerie.

    Vous pouvez aussi venir pour une première prise d’informations et de contacts.

    Nous vous attendons toujours plus nombreux

    [FR Bordeaux] Jeudi Giroll - Le jeudi 28 juin 2018 de 18h30 à 20h30.

    Les membres du collectif Giroll, GIROnde Logiciels Libres, se retrouvent une fois par semaine, pour partager leurs  savoir-faire et expériences autour des logiciels libres.

    Le collectif réalise aussi une webradio mensuelle, tous les second mardis du mois, à retrouver en direct sur le site de Giroll.

     Ses rencontres sont ouvertes à tous.

    [FR Peymeinade] Install-Party GNU/Linux - Le jeudi 28 juin 2018 de 19h00 à 21h00.

    Désormais tous les 4ᵉˢ mercredi du mois, Clic Ordi et Linux Azur vous proposent une install-party ouverte à tous et gratuite.

    • Découvrez un monde rempli de Papillons, licornes, mais surtout de manchots
    • Plus besoin de se soucier des virus et autres logiciels malveillants.
    • Le support de Windows Vista s’arrête dans un an, et les principaux logiciels ont déjà arrêté leurs mise à jour, réagissez
    • Ramenez vos ordinateurs obsolètes et donnez leur une seconde vie.

    Nous aimerions développer autour de Handy-Linux (et de sa future mouture avec Debian-Facile) afin de répondre à des besoins simples pour des personnes difficiles à former et pouvant se retrouver en fracture numérique).

    Nous sommes ouverts à tout, y compris à la bidouille sur l’atelier avec le fer à souder.

    Organisé conjointement par http://clic-ordi.com/fr et https://www.linux-azur.org

    [FR Vesseaux] Projection-débat du film « Nothing to hide » - Le jeudi 28 juin 2018 de 19h00 à 22h00.

    Ouverture des portes à 19h pour partager un moment de convivialité, discuter des choses et d’autres comme les logiciels libres, les données personnelles, la vie privée

    Il y a une buvette sur place, et vous pouvez également apporter un plat à partager ou biscuits apéro

    La projection du film documentaire Nothing to Hide aura lieu à 20h30, et sera suivie d’un débat pour répondre à vos questions

    « Dire que votre droit à la vie privée importe peu, car vous n’avez rien à cacher revient à dire que votre liberté d’expression importe peu, car vous n’avez rien à dire. Car même si vous n’utilisez pas vos droits aujourd’hui, d’autres en ont besoin. Cela revient à dire les autres ne m’intéressent pas », Edward Snowden

    Ce documentaire aborde le thème de la vie privée et des données personnelles.

    L’entrée est à prix libre (adhésion à l’association Vesseaux-Mère).

    [FR Paris] Soirée de Contribution au Libre - Le jeudi 28 juin 2018 de 19h30 à 22h30.

    Parinux propose aux utilisateurs de logiciels libres de se réunir régulièrement afin de contribuer à des projets libres. En effet, un logiciel libre est souvent porté par une communauté de bénévoles et dépend d’eux pour que le logiciel évolue.

    Nous nous réunissons donc tous les 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
    • en vente libre

    tout nouveau projet est le bienvenu.

    [FR Montpellier] Atelier du Libre Ubuntu et Logiciels Libres - Le vendredi 29 juin 2018 de 18h00 à 23h00.

    L’équipe de Montpel’libre vous propose une permanence Logiciels Libres, discussions libres et accompagnements techniques aux systèmes d’exploitation libres, pour vous aider à vous familiariser avec votre système GNU/Linux au quotidien.

    Le contenu de l’atelier s’adapte aux problèmes des personnes présentes et permet ainsi l’acquisition de nouvelles compétences au rythme de chacun.

    Vous pourrez y aborder plusieurs thèmes

    • Discussions conviviales entre utilisateurs autour de Linux en général
    • Préinscription aux prochains Cafés Numériques et Install-Party
    • Premières explorations du système
    • Installations et configurations complémentaires
    • Mise à jour et installation de nouveaux logiciels
    • Prise en main, découverte et approfondissement du système

    Les Ateliers du Libre ont lieu à la Mpt Melina Mercouri de Montpellier, tous les derniers vendredis de chaque mois de 18h00 à 20h00, sauf période de vacances.

    Entrée libre et gratuite sur inscription. Une simple adhésion à l’association est possible et auprès de la Mpt.

    Cet événement est proposé par le partenariat qui lie la Mpt Melina Mercouri de Montpellier et Montpel’libre.

    Toute une équipe de passionnés, vous propose l’animation de l’Atelier du Libre par les membres de Montpel’libre. Permanence Logiciels Libres, discussions libres et accompagnements des utilisateurs aux systèmes exploitation libres, Linux, sur le cyberespace de consultations libres.

    En fin de soirée, l’atelier fera progressivement place à un instant très convivial, les RDVL sont des rendez-vous mensuels de discussions sur le thème des logiciels libres, des arts libres, de l’open source et plus généralement de la culture du libre et du numérique.

    Cette soirée, très conviviale, se passe autour d’un repas partagé, chacun porte un plat, entrée, spécialité, dessert, boisson… Ordinateurs et réseaux disponibles.

    Notre équipe vous attend pour répondre à vos questions et satisfaire votre curiosité.

    Maison pour tous Mélina Mercouri 842, rue de la vieille poste, 34 000 Montpellier

    Bus ligne 9, La Ronde arrêt Pinville
    GPS Latitude 43.61354 Longitude 3.908768
    Carte OpenStreetMap

    Rendez-vous mensuel, tous les derniers vendredis, salle jamais le dimanche

    [FR Paris] Apéro April - Le vendredi 29 juin 2018 de 19h00 à 22h00.

    Un apéro April consiste à se réunir physiquement afin de se rencontrer, de faire plus ample connaissance, d’échanger, de partager un verre et manger mais aussi de discuter sur le logiciel libre, les libertés informatiques, fondamentales, l’actualité et les actions de l’April…

    Un apéro April est ouvert à toute personne qui souhaite venir, membre de l’April ou pas.

    N’hésitez pas à venir nous rencontrer.

    Où et quand cela se passe-t-il

    L’apéro parisien aura lieu vendredi 29 juin 2018 à partir de 19h00 dans les locaux de l’April.

    L’adresse
    April, 44/46 rue de l’Ouest, bâtiment 8, 75 014 Paris (entrée possible par la place de la Catalogne, à gauche de la Biocoop, au niveau des Autolib).
    Métros Gaîté, Pernety, Montparnasse. Sonner à « April » sur l’interphone.
    Le téléphone du local 01 78 76 92 80.

    L’Apéro a lieu à Paris notamment parce que le local s’y trouve ainsi que les permanents et de nombreux actifs. Pour les apéros dans les autres villes voir sur le pad plus bas.

    En ouverture de l’apéro nous ferons un court point sur les dossiers/actions en cours.

    Le glou et le miam

    Vous pouvez apporter de quoi boire et manger afin de reprendre des forces régulièrement. Nous prévoirons bien sûr un minimum vital.

    Vous pouvez vous inscrire sur le pad.

    [FR Dijon] Atelier de création numérique et électronique - Le vendredi 29 juin 2018 de 20h30 à 23h59.

    Le fablab et hackerspace l’abscisse vous propose comme tous les vendredis soir un atelier de création numérique et électronique.

    L’atelier est équipé de différents outils perceuse, CNC, Arduino, Raspberry Pi, ordinateurs, oscilloscope, multimètre.

    Une ressourcerie est à disposition, vous y trouverez des composants électroniques et des pièces détachées à prix libre.

    Vous pouvez venir découvrir l’atelier et les usagers du fablab à partir de 20h30.

    Vous pouvez aussi venir pour participer aux travaux numériques en cours, partager vos connaissances et vos savoir-faire.

    Tous nos travaux sont libres et documentés sous licence libre.

    [FR Saint-Jean-de-Védas] Repair Café - Le samedi 30 juin 2018 de 09h00 à 13h00.

    Nous vous proposons ce rendez-vous, où, bricoleurs, acteurs, bénévoles, associations, vous attendent pour vous aider à donner une deuxième vie à vos objets.

    Réparer ensemble, c’est l’idée des Repair Cafés dont l’entrée est ouverte à tous. Outils et matériel sont disponibles à l’endroit où est organisé le Repair Café, pour faire toutes les réparations possibles et imaginables. Vêtements, meubles, appareils électriques, bicyclettes, vaisselle, objets utiles, jouets, et autres. D’autre part sont présents dans le Repair Café des experts bénévoles, qui ont une connaissance et une compétence de la réparation dans toutes sortes de domaines.

    On y apporte des objets en mauvais état qu’on a chez soi. Et on se met à l’ouvrage avec les gens du métier. Il y a toujours quelque chose à apprendre au Repair Café. Ceux qui n’ont rien à réparer prennent un café ou un thé, ou aident à réparer un objet appartenant à un autre. On peut aussi toujours y trouver des idées à la table de lecture qui propose des ouvrages sur la réparation et le bricolage.

    Repair Café est un atelier consacré à la réparation d’objets et organisé à un niveau local, entre des personnes qui habitent ou fréquentent un même endroit, par exemple un quartier ou un village. Ces personnes se rencontrent périodiquement en un lieu déterminé, dans un café, une salle des fêtes ou un local associatif où des outils sont mis à leur disposition et où ils peuvent réparer un objet qu’ils ont apporté, aidés par des volontaires.

    Les objectifs de cette démarche alternative sont divers

    • réduire les déchets
    • préserver l’art de réparer des objets
    • renforcer la cohésion sociale entre les habitants des environs

    Seront présents

    • Autour.com : On se rend des services entre voisins, on partage des infos, on prête, on loue, on donne…
    • L’Accorderie : Est un système d’échange de services entre habitants d’un même quartier ou d’une même ville.
    • La Gerbe : Contribuer à la formation de citoyens éveillés, engagés et solidaires en offrant aux enfants et aux jeunes un espace privilégié d’expression et d’épanouissement Crèche, Centre de loisirs, Scoutisme, Ateliers, chacun peut y trouver un cadre pour son développement grâce au travail d’une équipe de professionnels et de bénévoles.
    • Les Compagnons Bâtisseurs : Prévoient d’amener des outils
    • Les Petits Débrouillards : est un réseau national de culture scientifique et technique, ils viendront avec pleins de conseils et une imprimante 3D.
    • Le Faubourg : Hébergera le Repear Café.
    • Montpel’libre : Sera là avec des pièces informatiques, pour essayer de reconditionner des ordinateurs, dépanner ceux qui ne fonctionnent plus, expliquer comment ça marche, faire comprendre le choix judicieux du logiciel libre, contourner l’obsolescence programmée grâce à GNU/Linux, comment réparer et entretenir son matériel soi-même, nous porterons un jerry.
    • TechLabLR : Accompagne les projets à composantes technologiques afin de les amener au pré-prototype, puis les guider vers les structures d’accompagnements.
    • Violons Dingues : Passionnés de la vie, des autres, de la culture, de l’art, du sport, de la mécanique, de la moto, de la photo, de la musique, des animaux, des insectes, des plantes, de l’environnement, enfin de tout ce qui circule (au propre comme au figuré) sur notre planète.
    • Zéro Waste Montpellier : La démarche « Zéro Waste » est une démarche positive pour aller vers une société zéro déchet et zéro gaspillage.

    • Maison des Associations, 18 bis rue Fon de l’Hospital, Saint-Jean-de-Védas, Occitanie, France

    • Adresse web http://montpel-libre.fr

    • Tags
      montpel-libre, repair-cafe, atelier

    [FR Casseneuil] Install Partie GNU/Linux - Le samedi 30 juin 2018 de 10h00 à 17h00.

    Le Samedi 30 Juin les bénévoles d’aGeNUx sont invités dans les locaux d’Avec 2L pour une Install-party.

    Venez découvrir et partager le monde du logiciel libre en toute sérénité.

    Animation Libre et non payante.

    Auberge Espagnole le midi.

    Avec 2L se situe derrière la poste de Casseneuil

    [FR Wintzenheim] Réunion du Club Linux - Le samedi 30 juin 2018 de 13h00 à 19h00.

    Comme tous les 3 samedis, le Club Linux de la MJC du Cheval Blanc se réunit et accueille toutes les personnes qui souhaitent découvrir ou approfondir Linux et les Logiciels Libres. Aucune compétence n’est demandée.  

    Pendant ces rencontres, informelles,

    • nous accueillons celles et ceux qui cherchent une réponse ou souhaitent découvrir Linux et les Logiciels Libres,
    • nous installons Linux sur des ordinateurs, la plupart des fois en « dual boot »(*), ce qui permet de conserver l’ancien système (par exemple Windows) et d’utiliser quand même, en choisissant au démarrage,
    • nous partageons nos recherches et nos découvertes, les nouveautés.

    Le Club Linux est également impliqué dans une démarche de libération des GAFAM (Google Apple Facebook Amazon Microsoft) et de promotion de solutions libres comme, entre autres, Wikipedia, Openstreetmap, les Framatrucs (*), les Chatons (*) et beaucoup d’autres.

    (*) : mais on vous expliquera

    [FR Villefranche-sur-Saône] Repaircafé - Le samedi 30 juin 2018 de 13h30 à 17h30.

    Dernier Repaircafé caladois mensuel de la saison avant les vacances.

    Avec la participation habituelle de la CAGULL.

    [FR Marseille] Install Party GNU/Linux - Le samedi 30 juin 2018 de 14h00 à 19h00.

    L’association (CercLL d’Entraide et Réseau Coopératif autour des Logiciels Libres) vous invite à une install party GNU/Linux, le, dans la salle du Foyer du Peuple 50 rue Brandis 13 005 Marseille.

    Vous avez envie de découvrir un système d’exploitation libre, simple d’utilisation, stable, rapide et sécurisé. Une nouvelle façon d’utiliser votre ordinateur.

    Vous vous sentez une affection naissante pour le Gnou et le, les mascottes de

    Au programme

    DÉCOUVERTE de l’univers des logiciels libres.

    INSTALLATION d’un environnement GNU/ Linux, ainsi que le meilleur des logiciels libres.

    Venez avec votre ordinateur, nous installerons ensemble une distribution avec un ensemble de et pour une utilisation quotidienne.

    Ouvert à tous – accessible aux débutant-e-s

    Une participation de 2 euros est demandée.

    L’adhésion à l’association est de 20 euros annuelle.(L’adhésion n’est pas obligatoire).

    Plan d’accés

    [BE Liège] Linux Install Party - Le samedi 30 juin 2018 de 14h00 à 18h00.

    Une Linux Install Party a lieu tous les derniers samedis du mois de septembre à juin, dans les locaux du Cyber Seniors Énéo de Grivegnée, où je suis animateur.

    L’accès et la participation à l’Install Party est ouvert à tous et est gratuit.

    Vous venez avec votre ordinateur et on y installe le Linux que vous désirez.

    Les installations commencent à 14h et finissent à 18h.
    Prévoyez de venir avant 17h, parfois ça peut durer longtemps.

    [FR Ivry sur Seine] Cours de l’Ecole du Logiciel Libre - Le samedi 30 juin 2018 de 14h30 à 18h30.

    Présentation de l’E2L

    Quel est le rôle de l’école du logiciel libre

    Tout d’abord, ce n’est pas une école comme les autres. Elle n’a pas d’établissement fixe, pas de cours de récréation, pas de carte d’étudiant, ni de diplôme de fin d’année.

    Comme toutes les écoles, son rôle est d’apprendre à ses élèves les logiciels libres, c’est-à-dire

    • comment en trouver de bons parmi les nombreux sites qui en proposent,
    • comment en prendre possession en fonction des licences,
    • comment les installer en fonction de ses besoins,
    • comment les tester et les utiliser,
    • comment en comprendre le fonctionnement pour ensuite les modifier,
    • comment écrire ses propres logiciels libres.

    En fait, l’école du logiciel libre est une université populaire, comme celles qui ont vu le jour en France à partir du 19ᵉ siècle, et dont le but est de transmettre des connaissances théoriques ou pratiques à tous ceux qui le souhaitent. Et pour atteindre ce but, sa forme juridique est de type " association à but non lucratif ".

    Comment fonctionne l’école

    Cette école étant une association, elle possède, comme toutes les autres, un bureau, élu chaque année en assemblée générale, pour l’administrer. Mais elle a aussi des responsables pédagogiques dont le rôle est essentiel, car ce sont eux qui établissent les programmes des cours en fonction des souhaits des adhérents, valident les candidatures des enseignants et affectent les sessions.

    Les membres du bureau et les responsables pédagogiques forment « l’encadrement de l’école ». Tous les membres « encadrants » doivent être membres de l’association.

    Les locaux où se déroulent les cours seront ceux que l’on veut bien nous prêter une salle des fêtes, un théâtre, une salle de réunion publique, un amphi dans une école publique, ou autre.

    Les thèmes des cours sont définis par les adhérents en fonction de leurs envies, de leurs besoins. Les cours sont ensuite décidés par les responsables pédagogiques de l’école en fonction des enseignants disponibles.

    Afin de permettre au plus grand nombre de participer et d’assister aux cours, les sessions se tiennent essentiellement le samedi. Une première de 9h à 12h30, et une autre de 14h à 17h30.

    Programme détaillé sur le site http://e2li.org

    [FR Courbevoie] Assemblée Générale annuelle de l'association StarinuX - Le samedi 30 juin 2018 de 14h30 à 17h00.

    L'association GULL StarinuX vous invite à  son

    ASSEMBLÉE GÉNÉRALE annuelle

    le samedi 30 juin 2018 à 14h30,

    48 rue de Colombes 92 400 Courbevoie

    (SNCF Gare de Courbevoie,  Saint Lazare <=> La Défense).

    Seuls les adhérent(e)s peuvent voter, mais les discussions restent ouvertes à tous les présents.

    Un déjeuner facultatif aura lieu à 12h30.

    Au plaisir de nous rencontrer à l’AG 2018

    Le Bureau de StarinuX

    [FR Poucharramet] Festival AgitaTerre - Le dimanche 1 juillet 2018 de 09h30 à 23h00.

    L’association 3PA Formation vous invite à la cinquième édition du Festival AgitaTerre Nous vous donnons rendez-vous le dimanche 1er juillet au coeur du village de Poucharramet (31), entre la place des Marronniers et La Maison de la Terre

    Venez découvrir des alternatives durables, locales et citoyennes qui font vivre notre territoire. Cette année, le festival investit le thème des Communs venez en apprendre plus

    Un événement gratuit et tout public

    9h30-18h

    Marché de producteurs et artisans-créateurs locaux
    Forum associatif & Village des Communs

    Conférences
    Expositions « C’est quoi les Communs »
    Ateliers tous publics

    Expositions d’artistes sculpteurs sur bois
    Mur d’expression libre
    Vannerie géante collective

    Concerts
    Spectacles et animations

    Buvette & Restauration
    Espace enfants

    20h30 Grand concert en plein air avec notre partenaire La Maison de la Terre

    Programmation et exposants sur www.agitaterre.fr

    Infos agitaterre@3paformation.fr // 3PA 05.61.08.11.30

    Parking sur place
    Adapté aux personnes à mobilité réduite

    Commentaires : voir le flux atom ouvrir dans le navigateur

  • Rumeurs sur l'hyper-threading - TLBleed (Journaux LinuxFR)

    La peinture de la dépêche sur la faille Lazy FPU save restore n'étais pas encore sèche
    que je tombais sur de curieux messages conseillant de désactiver l'Hyper-threading.

    Suivis de conversations plus ou moins inquiétantes sur Twitter et dans les mailings list.

    Accroche toi au pinceau

    Un commit sur OpenBSD désactive l' Hyper-treading par défaut.
    Le message associé est explicite:

    « Since many modern machines no longer provide the ability to disable Hyper-threading in
    the BIOS setup, provide a way to disable the use of additional
    processor threads in our scheduler. And since we suspect there are
    serious risks, we disable them by default
     »
    Puisque les machines récentes ne donnent plus la possibilité de désactiver l' Hyper-threading depuis le BIOS, trouvez un moyen de désactiver l'utilisation des threads d'un processeur dans notre ordonnanceur.
    Et comme on suspecte que le risque est sérieux, désactivons le par défaut.

    Pour faire plus court, j'avais lu auparavant un laconique:

    ps deactivate Hyper-threading on your server
    Désactivez l'Hyper-threading sur vos serveurs !

    Venant des équipes OpenBSD, il y a de quoi s'interroger.

    J'enlève l'échelle

    La conférence Black Hat qui se déroulera en août prochain, propose au menu:

    « This therefore bypasses several proposed CPU cache side-channel protections. Our TLBleed exploit successfully leaks a 256-bit EdDSA key from libgcrypt (used in e.g. GPG) with a
    98% success rate after just a single observation of signing operation on a co-resident hyperthread and just 17 seconds of analysis time
     »
    En outre, ceci court-circuite plusieurs protections sur le cache. Notre exploit TLBeed a réussi à voler une clef 256-bit EdDSA depuis ligcrypt (utilisée par GPG ) dans 98% des tentatives, après une simple observation des opérations de signature depuis un thread tournant sur le même CPU en seulement 17 secondes d'analyse.

    Colin Percival, auteur en 2005 de:

    1. un papier sur les attaques via les caches, Cache Missing for Fun and Profit
    2. un article qui cible plus particulièrement les risques liés à l'Hyper-threading

    en remet une couche:

    « I think it's worth mentioning that one of the big lessons from 2005 is that side channel attacks become much easier if you're executing on the same core as your victim »
    Je pense qu'il est bon de rappeler cette grande leçon de 2005: une attaque en side channel est tellement plus facile si vous l'exécutez sur le même cœur que votre victime.

    Cuisine

    Intel n'est jamais clairement impliqué; mais je précise, comme ça, en passant, que l'Hyper-Threading est une implémentation Intel du Simultaneous Multi Threading.
    Il s'agit de faire exécuter en parallèle, sur un même cœur, plusieurs unités fonctionnelles ou de calcul.
    Et pour rendre cette technique efficace et moins gourmande en ressource, cette implémentation partage aussi les caches mémoires.

    Keep systems protected, efficient, and manageable while minimizing impact on productivity

    Conclusion

    Toutes les solutions de sécurité aujourd’hui ne sont que des châteaux forts construit sur du sable.

    Si encore une fois, la désactivation de l'Hyper-threading pourrait même avoir des effets positifs sur les performances, autant en finir une fois pour toute.

    Retour aux origines:

    • un partage complet sans protection des ressources
    • plus de mode protégé
    • pas même de segmentation mémoire

    Vos machines iront encore plus vite. Enfin, j'espère.

    Commentaires : voir le flux atom ouvrir dans le navigateur

  • Tutoriel 3D - 2D découpe au laser, le retour du tux (Journaux LinuxFR)

    Sommaire

    Tranche de pingouin

    Chose promise, cause perdue. Voici comment transformer un modèle 3D en tranches de bois pour découpe laser. Et en bonus, mon essai initial de découpe en création originale.

    Les outils que j’ai utilisé sont blender et inkscape, et ce juste parce que je les connaissais et donc plus facile pour expérimenter.

    Note aux amateurs de freecad, j’ai commencé à regarder comment ça marche, au cas où ce serait plus simple avec, si jamais je trouve une idée et le courage de refaire un tuto, ça me fera un zeugma.

    Au début était le cube

    Ouvrir un nouveau fichier dans blender et mettre la scène en métrique, car sinon les mesures ne sont pas fixées par taille réelle. Notez que à chaque étape du tuto on aura des soucis de conversion de dimensions, donc en fait… mais bon faut pas en profiter pour être négligent.

    où trouver le changement metrique

    Retirer le cube et ajouter le Tux à la scène. Vous pouvez le trouver ainsi que toutes les licences à Tuuuuuuux

    • Faire face au tux (1 au pavé num)
    • Mettre la vue iso (5 au pavé num)
    • sélectionner le tux
    • passer en editor mode (tab)
    • Sélectionner le dessous des pattes (B) qui est rond
    • Niveler (SZ0)
    • sélectionner les deux centres des pattes, (S) Snap cursor to selected
    • rebasculer en object mode (tab) , transform origine to 3d cursor (object/transform)

    Maintenant, le tux est calé pour avoir le plancher des pattes en comme origine, à la verticale du pseudo centre de gravité que nous venons de choisir.

    mettre la bête en Z 0.

    Il est gros vot manchot ?

    Il nous faut choisir une taille, suffisamment grosse pour que ce soit cool, et pas trop gros pour limiter le prix. Comme l’objet c’est aussi tester une bonne quantité d’épaisseurs pour voir comment ajuster la taille théorique d’une planche par rapport à sa taille réelle (il reste du vide, la colle ça épaissit, les planches sont pas forcément pile à la taille).

    Une planche 2mm chez sculpteo (chez qui je teste la découpe laser) fait 94cm*59cm, il faut aussi essayer de rester dans une seule planche avec tous les morceaux. Le tux est presque aussi large que haut, du coup on cherche une approximation de cube découpé en tranches et étalé fait la même surface en gardant un peu de marge. ça fait 55 tranches, donc une hauteur de 116.875mm

    Et si on l’écartelait ?

    Il nous faut séparer les pattes du corps du tux (ce sont des objets distincts dans le modèle de base en fait et elles s’interconnectent :

    Tux pattes interconnectées

    Il faut les réunir par booléen union au corps pour avoir un seul objet avec un intérieur/extérieur propre.

    tux vue pattes melees

    On peut maintenant appliquer une subdivision sur le tux CTRL+3, parce que le tux aime la douceur, et pas que celle angevine.
    c'est mieux avec les pattes creuses, c'est comme les heures à l'edf

    Lui sculpter des yeux plus sympa, parce que même si tout le monde ne veut pas l’avouer, pour avoir l’air cool faut quand même avoir un peu l’air con.

    tux sculptation des yeux (ou sculptage selon les régions)

    la même en couleur

    Mais quand est-ce qu’on coupe ?

    Patience, il faut regarder un peu avant de couper. Placer un plan plus grand que le tux au sol, genre 20cmx20cm et lui appliquer un booléen d’intersection avec le tux. Et regarder en bougeant le plan sur Z comment seront les tranches.

    On voit deux endroits à problème, les ailes et la queue qui auront des tranches avec plus que un morceau, ce qui est plus complexe à coller.

    par ex les ailes :

    ailes dissociées

    Ce sera lourd à coller ensuite, on peut mais pourquoi…

    autant relier les ailes au tronc le plus légèrement possible, avec un lien de 1mm de large.

    idem au niveau de la queue :

    queue perdue

    J’ajoute un bloc en union au niveau de la queue, le plus ajusté possible par un booléen union.

    jointure queue

    Cela vous permettra de facilement coller, il sera toujours possible de le limer après collage.

    Il faut bien nettoyer le résultat de l’union à l’intérieur du tux, ne pas laisser de cloisons internes, c’est à dire éviter d’avoir des plan à l’intérieur des plans :

    retirer les morceaux à l’intérieur des autres

    Finir de nettoyer en retirant les doublons de vertices, boucher les trous, assurer les normales pour que ce soit clair ce qui est à l’intérieur et à l’extérieur.

    Et si on l’empalait ?

    Pensons au support central qui va nous permettre de facilement positionner et coller les tranches de tux, il va être en trapèze et ressembler à ça au niveau d’une tranche :

    plan des tranches

    Le choix de la découpe sera donc toujours du côté le plus grand, en bas. Donc notre référence pour le positionnement des plans de découpe doit être la face basse de chaque tranche.

    Replaçons le plan à 0.01mm en Z (pour éviter le chevauchement parfait des surface avec les pattes Z=0), pensez à remettre tous les éléments avec scale=1 (Ctrl+A scale and rotation) pour la suite.

    Faire une array de 50 plans en Z espacés de 2.125mm, faire le booléen intersection avec le tux. Lors de la réalisation de mon bureau réel avec des tux, j’ai constaté que l’empilage de x tranches de 2mm n’a pas un résultat de x*2mm, mais avec l’air restant et la colle environ 2.125. Je vais affiner avec ce tux cette estimation mais déjà on part de 2.125mm par tranche.

    On voit les tranches et on voit des petits problèmes

    problème de tranche

    Une tranche qui manque en haut et le cul qui a une mini tranche en bas.

    Diminuer le overlap thresold du booléen pour que le problème du haut disparaisse :

    option thresold

    Remonter le point du bas du tux pour supprimer le second problème et non, ce n'est pas lui mettre un doigt dans le cul car ça ne doit pas rentrer :

    trou du cul de tux

    Nickel !

    bonnes tranches

    Simulons une épaisseur des tranches pour avoir un aperçu du résultat réel, ajoutons au plan un modifier solidify 2mm avec l’offfet à +1 (vers le haut) pour suivre le plan d’avoir la face basse comme référence :

    simul résultat final

    Le résultat est conforme, retirez le solidify, il ne doit pas interférer avec l’étape de création du lien central.

    On l’empale plus ?

    Mais si, mais si. En fait ce n’est pas obligatoire, mais ça facilite le positionnement des étages, et on peut aussi le garde sans le coller. Le lien central doit avoir une forme de trapèze et être parfaitement vertical, car pour l’instant sculpteo ne fait pas de découpe oblique.

    Il doit faire une épaisseur égale à celle du bois. Pour mon exemple je suis resté sur mon approximation (2.125mm) mais normalement il faut prendre 2mm et ajuster avec l’épaisseur du kerf qui est la taille du laser laissant un vide de découpe autour du trait de coupe. En pratique lors de mon premier essai j’ai eu des soucis d’épaisseur et j’ai du poncer mon trapèze. Du coup comme ce n’est pas nécessaire d’ajuster. Je surestime cette fois-ci la taille du trapèze.

    trapeze

    Il faut ajuster sa position pour qu’il traverse tout le tux, coup de chance c’est possible sur ce modèle en plaçant la traverse au centre de la dernière tranche du tux. Mais sinon on l’aurait simplement fait avec deux trapèzes sur deux hauteurs.

    Ajustez la taille en X et la hauteur de la partie haute pour faire joli, elle va dépasser un peu et même arrondir sa tête (note postérieure en pratique le trapèze sera toujours trop court, il faut juger les tranches encore un peu plus grand que 2.125mm).

    tete de tux

    En dessous ajuster aussi la taille en X pour donner un beau trapèze

    mise en trapeze

    On voit que c’est moche au niveau du pied

    tux chaplin

    On va donc remodeler un peu le trapèze pour qu’il soit plus joli à cet endroit.

    remodelage du pied

    aspect final

    Parlons peu, parlons kerf

    Le kerf c’est la partie du bois éliminée par le laser, en pratique la découpe est plus petite que le plan car le laser à une taille non ponctuelle. la découpe de la traverse dans les tranches sera donc un peu plus grande que prévu, et la traverse découpée plus court aussi que prévu.

    Dans ce modèle, on peut ignorer le kerf et accepter les différences, elles seront minimes et les pièces collées seront bien ajustées.

    appliquons donc le booléen différence entre le plan des tranches et la traverse

    Le résultat est difficile à voir mais en vue fil de fer c’est visible

    vue fil de fer du tux trapeziste

    C’est la lutte finale

    On peut passer à la phase finale, on réalise les “modifier” sur les planches, puis on aplati le trapèze en retirant les vertices d’un côté.

    En mode éditeur, on sépare toutes les tranches (P+loose parts en mode édition) et on les étale dans le bon ordre en vue du dessus. Attention, les numéros générés lors de la réalisation de l’array ne sont pas forcément dans l’ordre de Z…

    Pour ne pas me planter, je me met dans une vue adaptée et je bouge une par une les tranches avec des gx0.1 … Je vérifie bien que tout est dans l’ordre puis je met tout le monde à plat (sélectionner tout A puis SZ0)

    Nous allons avoir des soucis de conversion de taille entre blender puis Inkscape puis sculpteo… on commence par poser un étalon dans blender, un plan au sol de 1cm sur 90cm

    90cm etalon

    Le petit oiseau va sortir

    Enfin presque, il faut encore à faire la photo !

    Il existe une option de rendering qui génère du svg.

    Mettons la caméra au dessus en mode orthographique, d’abord une résolution 100% sur un ratio approximatif de mon rectangle incluant tout.

    100 pourcent

    puis placer la caméra assez bien au dessus de la scène et changez les paramètres :

    ortho

    L’échelle orthographique est ce qui correspond au zoom, ajustez la valeur pour que tout rentre au plus juste

    Tout doit rentrer dans la fenêtre de rendering :

    serrez les rangs

    Maintenant depuis les user pref, activez le svg freestyle exporter :

    options rendering

    Et activez les deux options freestyle et svg export depuis les options rendering

    option rendering activee

    Pressez F12, une image svg sera générée dans le répertoire indiqué dans output nommé 0001.svg,

    Ouvrez le dans Inkscape, dégroupez et sélectionnez l’étalon. mettez lui une épaisseur de contour à 0 pour ne pas fausser la taille et regardez sa taille. Dans mon cas je tombe sur 35.719cm.

    Je vais donc changer la résolution de l’image pour ajuster la taille d’un facteur de 90/35.719=2.52

    Je change dans blender le render pour :

    retailler

    Re F12 et vérification.

    Mon étalon fait maintenant 1cm sur 90.01cm.

    aller, on essaie avec un pixel de moins en Y :), on tombe sur 89.987. C’est moins bon, retour en arrière.

    Maintenant que l’on a les bonnes tailles dans Inkscape, il faut nettoyer. Parce que le freestyle a introduit des pixels de temps en temps.

    Je prends donc chaque découpe pour la repositionner au mieux et aussi supprimer les traces.

    points artefacts

    Pour m’aider et aussi servir d’étalon entre Inkscape et sculpteo je place un cadre dans une autre couleur qui délimite ma sélection, 53.5cm de large sur 75cm de haut.

    Et je fais tout rentrer dedans.

    Je vérifie chaque pièce pour assurer qu’il n’y a pas de défaut, et j’assure les contours à 1px et mon cadre avec une couleur différente

    C’est prêt.

    planche à découper

    Pour ceux qui sont plus observateurs que moi, vous verrez que j’ai oublié de grouper une fente dans une tranche. Moi je vais le voir au montage plus tard…

    TuxOlaser

    J’upload chez sculpteo.

    Deux couleurs sont détectées, l"une correspond au noir et l’autre au rouge du cadre. Les mesures n’ont pas été conservées, je ne sais pas pourquoi… mais mon cadre me permet de choisir un ajustement de taille à 26.5% qui me redonne les bonnes dimensions.

    Je peux alors désactiver le cadre rouge dans sculpteo (style 2 sur aucun et voila !

    prêt à couper.

    Livraison comprise il vous en coûtera 53.33€.

    Pour info, les tux du bureau ont coûté moins cher, ils étaient en une seule livraison et un peu plus petits, 72€ les 3.

    Déboitage du tux et montage

    Je hais les video de unboxing, et me voilà moi même à déboiter…

    Bon, puisqu’il faut :

    la boite est bien protégée

    boite

    et la planche dans la mousse

    planche entourée de mousse

    Les pièces sont tenues par du scotch, il faudra faire attention en retirant le scotch de ne pas casser les pièces fragiles.

    scotch sur les pieces

    Je numérote mes pièces avant de défaire, c’est moins cher que de faire des numéros au laser.

    sans scotch à numéroter

    Ensuite on empile jusqu’à la fameuse pièce 33 qu’il faudra redécouper.

    debut d'empilage

    piece 33

    redecoupe de la 33

    piece 33 empilee

    Tadaaaa

    Entrer une description pour l'image ici

    A propos de licences

    J’ai fouillé pour trouver les licences attachées au modèle de base, les voici :

    https://opengameart.org/content/tux

    https://opengameart.org/sites/default/files/license_images/gpl.png

    http://www.gnu.org/licenses/gpl-3.0.html

    https://opengameart.org/sites/default/files/license_images/cc-by.png

    http://creativecommons.org/licenses/by/3.0/

    Les fichiers

    Voila les fichiers sources blender et le inkscape (piece 33 corrigée)

    fichier blender

    fichier svg

    Commentaires : voir le flux atom ouvrir dans le navigateur

  • Projet de tableau numérique interactif à base de Wiimote (Laboratoire Linux SUPINFO)

    Note: Cet article est le compte-rendu d'un projet personnel visant à créer un tableau numérique interactif avec une Wiimote comme composant principal. Vous pouvez télécharger le code source du logiciel ici (celui-ci se présente sous la forme d'un projet pour l'IDE Code-Blocks).

     

    1. L'idée du projet

    L'idée de ce projet m'est venue au cours d'une session sur le web. Je suis tombé sur un site qui vantait les mérites de ce qu'il appelait le TNWii ; c'est à dire un tableau numérique interactif basé sur les capacités des Wiimotes de la console de Nintendo.
    Le concept à été imaginé par Johnny Chung Lee, un chercheur sur les interactions homme-machine employé chez Microsoft. Il a pensé à réutiliser les caractéristiques de la manette de la console Wii et de la détourner afin d'en trouver d'autres utilisations.
    L'intérêt de cette manette est son capteur infrarouge. Il suffit de lui montrer une ou plusieurs source de lumière infrarouge et d'avoir le logiciel adéquat afin d'obtenir un outil de suivi de points basique. De plus, la Wiimote n'est pas filaire et utilise le protocole Bluetooth, ce qui permet donc de la relier facilement à un ordinateur.
    Johnny Chung Lee a abouti, entre autres choses, à la création d'un tableau numérique interactif. Son idée ayant fait des émules, différents logiciels ont été créés pour améliorer la chose, chacun fournissant plus ou moins de fonctions.
    Mais ces programmes sont en grande majorité écrits pour Windows, et n'ayant personnellement pas réussi à faire fonctionner les rares conçu pour les systèmes Linux, ainsi qu'étant curieux de connaître le fonctionnement d'un programme agissant avec un matériel de ce type, je me mis en tête de coder un logiciel basique pour Linux permettant de faire fonctionner la manette dans le cadre d'un tableau numérique.
    Bien qu'ayant un but fonctionnel, ce projet était principalement voué à m'apprendre des techniques avancées de programmation ainsi que le fonctionnement de petits matériels électronique.

     

    2. Description générale du tableau interactif et recherches préliminaires

    Le tableau interactif est constitué de quatre composants :

    • un projecteur qui affiche l'image de l'ordinateur contre un mur, un écran ou tout autre surface lisse.
    • un stylet infrarouge qui permet d'émettre un point de lumière sur la surface projetée afin d'indiquer un clic de souris.
    • une Wiimote qui récupère la position du point dans l'espace via sa caméra frontale et la transmet à l'ordinateur.
    • et enfin un ordinateur équipé d'un module Bluetooth (intégré ou sur un dongle USB) qui, grâce à un logiciel dédié, traite le signal reçu et effectue un clic de souris à l'emplacement du point infrarouge.

    Ceci donne donc juste la possibilité de faire un « clic gauche » de souris, mais certains logiciel plus évolués permettent d'effectuer des « clics droit » ainsi que d'autres actions.
    Possédant déjà une Wiimote ainsi qu'un ordinateur équipé d'une puce Bluetooth, il me restait donc à concevoir un stylet infrarouge ainsi qu'un programme dialoguant avec la Wiimote.

    Après quelques recherches plus poussées, je pus établir un plan des notions à assimiler et à mettre en pratique pour le développement du logiciel.
    La première chose à choisir était le langage de programmation à utiliser. J'avais tout d'abord opté pour le Python, dont l'interpréteur est très répandu sur les systèmes Linux et dont je possédait déjà des connaissances. Malheureusement, et bien que la bibliothèque de modules de Python soit très fournie, les rares modules conçus pour le support de Bluetooth sont trop anciens et obsolètes. Je me suis donc rabattu vers un autre langage de plus bas niveau : le C.
    Une interface graphique étant prévue pour mon logiciel, je choisis la bibliothèque graphique GTK+ car je l'avais déjà utilisé en Python.
    Ensuite il me fallait pouvoir communiquer avec la Wiimote. Or n'ayant aucune connaissance du protocole Bluetooth, j'allais devoir apprendre son fonctionnement.
    Une fois ceci fait, je devrai faire de même pour connaître la marche interne de la Wiimote ainsi que les commandes à lui envoyer pour lui faire effectuer les actions voulues.
    Il me resterai ensuite la création de l'algorithme de traitement des coordonnées des points infrarouges sur l'image projetée et leur interprétation pour les placer sur l'image réelle de l'écran d'ordinateur.
    Enfin, le tableau blanc interactif n'étant pas constitué de la seule Wiimote et d'un programme, il me fallait une source de lumière infrarouge qu'elle puisse capter. Cette source infrarouge serait incarnée ici sous la forme d'un stylet à construire moi-même.

    La liste des choses à faire ainsi que le choix des technologies faits j'allais pouvoir débuter la conception de mon TNWii.

     

    3. Construction de l'interface et prise en main du protocole Bluetooth

    J'ai donc commencé par faire un schéma afin de bien savoir visualiser ce qu'il y avait à construire au niveau de l'interface.

    Schéma d'interface du logiciel de tableau numérique à base de Wiimote.

    Cette interface est simple mais suffit à obtenir quelque chose de fonctionnel.

    La concrétisation de ce schéma ne m'a pas posé de vrai problème. Une fois que l'on a saisi le fonctionnement de la bibliothèque GTK+ la construction d'une interface n'est pas très compliquée.
    Voici par exemple ce que cela donne sur mon ordinateur :

    Interface du logiciel

    Là où les choses sont devenues plus difficiles, c'est lorsque j'ai dû utiliser le protocole Bluetooth. Celui-ci utilise les mêmes concepts de sockets que la programmation réseau classique, mais n'ayant pas non plus eu l'occasion de pratiquer cette dernière, j'ai dû tout apprendre de zéro. Cela m'a permis entre autre d'acquérir les notions de sockets, threads, mutex et endianess spécifiques à la programmation réseau.
    Mais au départ, j'ai quand même eu des problèmes pour trouver des ressources sur l'utilisation de la bibliothèque Bluez permettant l'accès à la pile Bluetooth sous Linux. Que ce soit en Français ou en Anglais, il y a très peu de documentation sur le sujet. C'est pourquoi, lorsque j'ai pu en trouver une de très bonne qualité, j'en ai effectué une traduction vers le Français car elle pourrait être très utile à tout développeur voulant utiliser le Bluetooth sous Linux.
    Ce document détaille l'utilisation des protocoles RFCOMM et L2CAP (équivalents de TCP et UDP) et donne des exemples d'implémentation. La version originale est disponible ici et ma traduction ici.

     

    4. Fonctionnement de la Wiimote

     

    4.1 Établissement de la connexion Bluetooth

    Le deuxième gros morceau de nouveauté à été la Wiimote. Connaître son fonctionnement n'est pas inné. Heureusement des hackers (au sens premier du terme, à savoir "bidouilleurs") ont effectué un gros travail de rétro-ingénierie, ce qui à aboutit à une documentation détaillant l'utilisation de chaque fonctionnalité pour les programmeurs et qui sera ma principale source de savoir.
    Je vais expliquer ici son fonctionnement en Français, car c'est l'un des buts de ce projet. Attention cependant, beaucoup de notions propres à Bluetooth sont utilisées donc il vaut mieux être à l'aise avec ce dernier.
    Pour établir la connexion avec la manette on utilise donc le protocole Bluetooth, mais il n'est pas nécessaire (bien que ce soit possible) d'effectuer un « pairing » avec celle-ci. Il suffit juste de la placer en mode découverte en appuyant sur le bouton « sync » (situé dans le compartiment des piles). Il est aussi possible, pour les Wiimote de première génération, d'appuyer sur les boutons 1 et 2 en même temps pour lancer le mode découverte.
    Le "nom convivial" (traduction de "friendly name") envoyé alors est RVL-CNT-01 pour les Wiimotes de première génération et RVL-CNT-01-TR pour celles de seconde génération.
    Une fois la découverte activée, deux PSM du protocole L2CAP sont prévus pour communiquer. Le PSM 0x11 est utilisé pour le flux de contrôle et le 0x13 pour le flux de données, bien que dans la réalité le 0x11 soit quasiment inutilisé.

    Note: Pour rappel, le protocole L2CAP est en quelque sorte un équivalent de UDP en Bluetooth et les PSM (pour « Protocoles Services Multiplexers ») sont les noms des ports de ce protocole. Ces numéros de PSM étant donnés en hexadécimal, nous avons ici donc en réalité les ports 17 et 19.

    Il suffit donc pour établir une connexion avec la manette, de la détecter, de récupérer son adresse MAC et d'y connecter un socket avec comme contexte d'adressage les informations données ci-dessus.

     

    4.2 Schéma général des communications

    Ensuite nous pouvons réellement dialoguer avec la Wiimote. Cela se fait par l'envoi de ce que l'on appel des rapports. Les rapports sont des messages constitués d'une suite d'octets dont la valeur est écrite en hexadécimal et qui suivent un format précis.
    Chaque type de rapport ne peut être envoyé que dans un sens. Un rapport entrant se fait dans le sens périphérique -> hôte et sera préfixé d'un octet contenant 0xa1 , alors qu'un rapport sortant se fait dans le sens hôte -> périphérique et débutera lui par un octet contenant 0xa2.

    Voici la liste des types de rapports disponibles pour communiquer avec la Wiimote :

    Sens ID Taille Fonction
    Sortant 0x10 1 Inconnue
    Sortant 0x11 1 Allumage des LEDs
    Sortant 0x12 2 Choix du mode de rapport pour les données envoyées par la Wiimote
    Sortant 0x13 1 Allumage de la caméra infrarouge (1ère partie)
    Sortant 0x14 1 Allumage du haut-parleur
    Sortant 0x15 1 Requête de demande de status
    Sortant 0x16 21 Écriture dans une mémoire ou un registre
    Sortant 0x17 6 Lecture d'une mémoire ou d'un registre
    Sortant 0x18 21 Envoie de données au haut-parleur
    Sortant 0x19 1 Passer le haut-parleur en muet
    Sortant 0xa 1 Allumage de la caméra infrarouge (2ème partie)
    Entrant 0x20 6 Informations de statut de la Wiimote
    Entrant 0x21 21 Données renvoyées lors de la lecture des mémoires et registre
    Entrant 0x22 4 Acquittement d'un rapport sortant (résultat du traitement du rapport ou code erreur)
    Entrant 0x30-0x3f 2-21 Données renvoyées par la Wiimote après le choix du mode de rapport de données.

    Les rapports envoyés ou reçus auront donc la forme suivante :

    Note: Dans la suite, pour les exemples de rapport comme celui ci-dessous, je n'inscrirai pas les 0x au début de chaque octet (bien qu'ils soient en notation héxadécimale) afin de rendre le contenu plus lisible.

    a1 30 00 00

    Ce rapport sera par exemple un rapport entrant (0xa1) contenant des données reçues de la Wiimote (0x30) et dont les deux derniers octets sont les données en question.

    Pour rappel, mon but est de localiser les points infrarouges vus par la Wiimote en récupérant leur coordonnées. Pour obtenir ces coordonnées il lui faut faire nous envoyer un rapport de données (les types 0x30 à 0x3f). Mais il existe plusieurs modes de rapports de données, chacun permettant de récupérer un contenu différent. Il faut donc sélectionner le mode de rapport que l'on veut obtenir. Cela se fait par l'envoi d'un rapport de type 0x12 dédié spécialement à ce choix.
    Le type de rapport 0x12 se présente ainsi :

    a2 12 TT MM

    Nous avons donc un premier octet pour le sens du rapport, un second pour le type, puis deux octets de contenu.
    Le premier octet de contenu, ici nommé TT, permet en activant son bit 2 (c'est à dire en mettant sa valeur à 0x04) de spécifier à la Wiimote que l'on veut qu'elle envoie des rapports de données en continu même si les valeurs sont restées inchangées. S'il est laissé à 0x00, ces rapports ne seront envoyés qu'à chaque changement de valeur.
    Le second, nommé MM, permet de choisir le mode de rapport proprement dit.
    Voici les différents modes disponibles :

    ID Contenu
    0x30
    a1 30 BB BB
    Ce mode retourne 2 octets ( BB ) contenants les valeurs des boutons appuyés de la Wiimote
    0x31
    a1 31 BB BB AA AA AA
    Ce mode retourne :
    • 2 octets ( BB ) contenants les valeurs des boutons appuyés
    • 3 octets ( AA ) contenants les données de l'accéléromètre
    0x32
    a1 32 BB BB EE EE EE EE EE EE EE EE
    Ce mode retourne :
    • 2 octets ( BB ) contenants les valeurs des boutons appuyés
    • 8 octets ( EE ) contenants les valeurs d'un périphérique d'extension que l'on peut brancher à la manette
    0x33
    a1 33 BB BB AA AA AA II II II II II II II II II II II II
    Ce mode retourne :
    • 2 octets ( BB ) contenants les valeurs des boutons appuyés
    • 3 octets ( AA ) contenants les données de l'accéléromètre
    • 12 octets ( II ) contenants les coordonnées des points détectés par la caméra infrarouge
    0x34
    a1 34 BB BB EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE
    Ce mode retourne :
    • 2 octets ( BB ) contenants les valeurs des boutons appuyés
    • 19 octets ( EE ) contenants les valeurs d'un périphérique d'extension que l'on peut brancher à la manette
    0x35
    a1 35 BB BB AA AA AA EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE
    Ce mode retourne :
    • 2 octets ( BB ) contenants les valeurs des boutons appuyés
    • 3 octets ( AA ) contenants les données de l'accéléromètre
    • 16 octets ( EE ) contenants les valeurs d'un périphérique d'extension que l'on peut brancher à la manette
    0x36
    a1 36 BB BB II II II II II II II II II II EE EE EE EE EE EE EE EE EE
    Ce mode retourne :
    • 2 octets ( BB ) contenants les valeurs des boutons appuyés
    • 10 octets ( II ) contenants les coordonnées des points détectés par la caméra infrarouge
    • 9 octets ( EE ) contenants les valeurs d'un périphérique d'extension que l'on peut brancher à la manette
    0x37
    a1 37 BB BB AA AA AA II II II II II II II II II II EE EE EE EE EE EE
    Ce mode retourne :
    • 2 octets ( BB ) contenants les valeurs des boutons appuyés
    • 3 octets ( AA ) contenants les données de l'accéléromètre
    • 10 octets ( II ) contenants les coordonnées des points détectés par la caméra infrarouge
    • 6 octets ( EE ) contenants les valeurs d'un périphérique d'extension que l'on peut brancher à la manette
    0x3d
    a1 3d EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE
    Ce mode retourne :
    • 21 octets ( EE ) contenants les valeurs d'un périphérique d'extension que l'on peut brancher à la manette
    0x3e-f
    a1 3e BB BB AA II II II II II II II II II II II II II II II II II II
    a1 3f BB BB AA II II II II II II II II II II II II II II II II II II
    Les rapports 0x3e et 0x3f sont, lorsqu'ils sont choisit, envoyés alternativement par la manette et retournent :
    • 2 octets ( BB ) à chaque rapport contenants les valeurs des boutons appuyés
    • 2 octets ( AA ) sur deux rapports (donc à ré-assembler) contenants les données de l'accéléromètre
    • 36 octets ( II ) sur deux rapport (donc à ré-assembler) contenants les coordonnées des points détectés par la caméra infrarouge

    Note: Dans la suite, je ne détaillerai que les types de rapport dont je me suis servi. C'est à dire majoritairement ceux en lien avec la caméra infrarouge de la manette.

    Suivant les différents modes, on peut constater que le nombre d'octets renvoyés pour les données infrarouge varie. Pour savoir quelle en est la raison, il faut se pencher sur le format de ces données renvoyées.

    4.3 Allumage et configuration de la caméra infrarouge

    La caméra de la Wiimote a une résolution native de 128x96, qui est ensuite augmenté 8 fois par un processeur interne faisant une analyse sous-pixel, et qui permet d'atteindre une résolution de 1024x768. La manette est capable de renvoyer au total les coordonnées de 4 points infrarouges.

    L'allumage et l'initialisation de la caméra se fait par l'envoi d'une suite de commande précise :

    1. Il faut en premier lieu l'activer en lui envoyant un rapport 0x13 dont le bit 2 de l'octet de charge utile sera à 1. Cette octet de charge utile aura donc la valeur finale de 0x04. :
      a2 13 04
    2. Puis faire de même en lui envoyant un rapport 0x1a dont le bit 2 de l'octet de charge utile sera lui aussi à 1. Cette octet de charge utile aura donc la valeur finale de 0x04. :
      a2 1a 04
    3. La troisième action consiste à écrire 0x08 dans le registre 0xb00030.
      Les registres sont des zones mémoire et écrire dedans se fait par l'envoi d'un rapport 0x16 formaté comme ceci :
      a2 16 MM FF FF FF SS DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD

      Avec :
      • MM pour sélectionner le type de mémoire sur laquelle on veut écrire. On peut le placer à 0x04 pour sélectionner les registres (zones de mémoire vive) ou le laisser à 0x00 pour utiliser la EEPROM (mémoire morte). Il faut bien faire attention à ne pas réécrire la EEPROM et bien placer cet octet à 0x04
      • FF les octets pour choisir le registre sur lequel écrire.
      • SS pour déclarer la quantité de données à écrire (en octets).
      • DD les données à écrire. Si les données ne prennent pas toute la place disponible (ce qui est notre cas), il suffit de remplir les octets restants avec la valeur hexadécimale ff.
      En remplaçant avec nos informations, nous obtenons le paquet ci-dessous :
      a2 16 04 b0 00 30 01 08 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    4. En quatre, il nous faut choisir la sensibilité de la caméra. Cela se fait en écrivant deux blocs de 9 et 2 octets respectivement dans les registres 0xb00000 et 0xb0001a.
      Voici un tableau des différentes valeurs (retrouvées par rétro-ingénierie) pour les deux blocs de sensibilités :
      Bloc 1 Bloc 2 Notes
      00 00 00 00 00 00 90 00 C0 40 00  
      00 00 00 00 00 00 FF 00 0C 00 00 Sensibilité maximale
      00 00 00 00 00 00 90 00 41 40 00 Haute sensibilité
      02 00 00 71 01 00 64 00 fe fd 05 Wii niveau 1
      02 00 00 71 01 00 96 00 b4 b3 04 Wii niveau 2
      02 00 00 71 01 00 aa 00 64 63 03 Wii niveau 3
      02 00 00 71 01 00 c8 00 36 35 03 Wii niveau 4
      07 00 00 71 01 00 72 00 204 1f 03 Wii niveau 5
      C'est le dernier octet du bloc 1 qui détermine l'intensité de la sensibilité, et plus sa valeur est grande, moins la sensibilité est élevée. Il est recommandé de placer la sensibilité aussi haut que possible, en évitant la pollution lumineuse autre que le stylet, pour pouvoir bénéficier au maximum de l'analyse sous-pixel du processeur de la Wiimote. Plus la sensibilité est réduite, plus la résolution sous-pixel l'est aussi, et plus on se rapproche de la résolution native de la caméra (128x96).
      Nous envoyons donc les deux rapports afin d'écrire dans les registres la sensibilité choisie :
      // Rapport d'écriture du bloc 1
      a2 16 04 b0 00 00 09 00 00 00 00 00 00 ff 00 0c ff ff ff ff ff ff ff
      // Rapport d'écriture du bloc 2
      a2 16 04 b0 00 00 02 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    5. La cinquième étape consiste au choix du mode d'envois des données par la Wiimote. Il existe trois modes différents renvoyant chacun des données de tailles différentes. Ces tailles correspondants à celles des différents modes de rapports de données vus plus haut. Il faudra donc choisir le mode de rapport de la Wiimote suivant le mode de données choisit pour la caméra.
      Mais ce qu'il faut savoir tout d'abord, c'est la façon dont la manette gère les points qu'elle voit. Elle dispose de quatre slots et lorsqu'elle reconnaît un point lumineux, elle l'associe aux premier slot disponible. C'est à dire que si un objet sort de son champs de vision puis revient, il retrouvera le numéro de slot qu'il avait auparavant.
      Ci-dessous un petit tableau des modes disponibles :
      Mode
      Numéro du mode
      Basique
      1
      Étendu
      3
      Complet
      5
      Et voici un descriptif de chaque mode :
      • En mode basique, la caméra retourne 10 octets de données correspondants aux coordonnées X et Y de chaque point. Chaque coordonnées est codée sur 10 bits et s'étend de 0 à 1023 pour les X et de 0 à 767 pour les Y. Les données retournées sont divisées en deux paquets de 5 octets contenants chacun les coordonnées de 2 points.
        Voici un schéma pour comprendre comment sont répartis les bits de chaque point :
         
        Bit
        Octet
        7
        6
        5
        4
        3
        2
        1
        0
        0
        X1
        1
        Y1
        2
        Y1
        X1
        Y2
        X2
        3
        X2
        4
        Y2
      • Le mode étendu est quasiment similaire au mode basique, à part le fait qu'une information en plus est embarquée pour chaque point, à savoir sa taille. Cette taille est une valeur estimé et va de 0 à 15. L'ajout de cette valeur fait que chaque point est codé sur 3 octets entiers. Il faut donc au total 12 octets pour transporter les valeurs des 4 points.
        Ci-dessous un tableau détaillant la façon dont sont organisés les bits de chaque points :
         
        Bit
        Octet
        7
        6
        5
        4
        3
        2
        1
        0
        0
        X1
        1
        Y1
        2
        Y1
        X1
        S
      • Enfin, en mode complet, chaque point est codé sur 9 octets. Les trois premiers octets contiennent les même informations que le mode étendu, auquel on ajoute les coordonnées de la surface englobant chaque point ainsi qu'une valeur de l'intensité perçue du point. Il faut donc un total de 36 octets pour transporter toutes ces informations, ce que seul permettent les rapports 0x3e et 0x3f combinés.
        Voici le schéma correspondant à la façon dont sont organisés les bits de chaque point dans ce mode :
         
        Bit
        Octet
        7
        6
        5
        4
        3
        2
        1
        0
        0
        X1
        1
        Y1
        2
        Y1
        X1
        Y2
        X2
        3
        0
        X min
        4
        0
        Y min
        5
        0
        X max
        6
        0
        Y max
        7
        0
        8
        Intensité
    6. Enfin, pour valider tous nos choix, il faut répéter l'étape numéro 3 en envoyant la valeur 0x08 au registre 0xb0003.

    Une fois cette série d'étapes effectuée, la Wiimote devrait commencer à renvoyer les octets selon le mode de rapport de données et le mode de la caméra infrarouge que l'on a choisi.

     

    4.4 Extraction des coordonnées des points reçues

    Il ne suffit pas de faire une conversion des octets reçus au format hexadécimal vers la notation décimale pour obtenir les coordonnées des points.
    Comme on l'a vu dans les tableaux précédents, les coordonnées X et Y sont chaque fois codées sur 10 bits répartis sur 2 octets. Il faut donc convertir les valeurs hexadécimales au format binaire, isoler les bits intéressants, les associer avec leurs correspondants et reconvertir le tout en décimal.
    Ça c'est pour la description rapide, je vais détailler ci-dessous la démarche complète.

    Note: Je ne traiterai ici que de la conversion d'un seul point, vu que c'est ce que j'aurai concrètement dans le cadre de mon tableau numérique. Mais de toute façon, une fois que l'on a compris la procédure avec un point, le faire pour quatre n'est pas plus compliqué.

    Tout d'abord, il faut savoir que j'ai choisi le mode basique comme organisation des coordonnées renvoyées par la caméra infrarouge car je n'ai seulement besoin que de ces coordonnées sans informations supplémentaires. Ce mode de caméra renvoyant 10 octets, je n'ai le choix comme type de rapport de donnée qu'entre les rapports 0x36 et 0x37. J'ai personnellement opté pour le type 0x36.
    Pour rappel, les rapports que je vais recevoir de la Wiimote auront la forme suivante :

    a1 36 BB BB II II II II II II II II II II EE EE EE EE EE EE EE EE EE

    Donc, si on les numérote à partir de 0, les octets correspondants aux données infrarouges vont du numéro 4 au numéro 13. Dans ces 10 octets, les 5 premiers contiennent les coordonnées des 2 premiers points et les 5 suivants ceux des 2 derniers points. N'ayant qu'un point à convertir nous allons nous concentrer sur les données des 5 premiers octets.
    Imaginons que ceux-ci aient les valeurs suivantes :

    57 A4 30 00 00

    D'après le tableau de description du mode basique, nous pouvons savoir que :

    • le premier octet (0x57) contient les 8 bits de poids faible de la coordonnée X du premier point
    • le deuxième octet (0xA4) contient les 8 bits de poids faible de la coordonnée X du premier point
    • le troisième octet (0x30) contient les 2 bits de poids fort des coordonnées X et Y du premier et second points.

    Les autres octets contenant seulement les coordonnées du point 2, qui sont vides et ne nous intéressent pas, nous les laissons de côté.
    Nous allons maintenant convertir en binaire les valeurs de ces trois octets :

    Numéro de l'octet
    Valeur Hexadécimale
    Valeur binaire
    0
    0x57
    01010111
    1
    A4
    10100100
    2
    30
    00110000

    Grâce à ces valeurs binaire on peut recomposer les coordonnées complètes de 10 bits. Pour mieux les discerner, je les ait placées dans le tableau présentant l'organisation des bits du mode basique :

     
    Bit
    Octet
    7
    6
    5
    4
    3
    2
    1
    0
    0
    0
    1
    0
    1
    0
    1
    1
    1
    1
    1
    0
    1
    0
    0
    1
    0
    0
    2
    0
    0
    1
    1
    0
    0
    0
    0
    3
    0
    0
    0
    0
    0
    0
    0
    0
    4
    0
    0
    0
    0
    0
    0
    0
    0

    Sont coloriés en orange les bits de la coordonnée X et en bleu les bits de la coordonnée Y.
    Et maintenant en réorganisant les bits et en faisant la conversion en décimal, on obtient les coordonnées compréhensibles :

    Coordonnée
    Réorganisation en binaire
    Valeur convertie en décimal
    X
    1101010111
    855
    Y
    0010100100
    164

    La conversion est finie. Dans mon programme j'ai implémenté cette même démarche afin d'effectuer la conversion des coordonnées.

     

    5. Conversion des points vus par la Wiimote en points à inscrire sur l'écran

    Les coordonnées des points vus par la Wiimotes ne sont pas applicables directement pour l'affichage à l'écran. Ceci pour deux raisons :

    1. La caméra de la manette n'a pas forcément la même définition que l'écran sur lequel on va afficher.
    2. Les coordonnées récupérées sont définies dans le repère formé par la résolution de la caméra de la Wiimote et non par rapport à l'image projetée de l'écran qui nous intéresse.

    Pour ces deux raisons, il faut donc effectuer une conversion. Ce qui nous fait rentrer dans le domaine de la vision par ordinateur.

    Pour expliciter un peu mieux la chose rien ne vaut un schéma :

    Schéma montrant la différence de coordonnées d'un point entre ce que voit la Wiimote et sa position réelle sur la zone affichée.

    Sur ce schéma, est délimité en bleu la zone visible par la Wiimote. Celle-ci est rectangle et mesure 1024x768 pixel.
    Ensuite en vert, est symbolisé le périmètre de l'écran projeté et vu par la manette. Il n'est pas forcément aligné avec le cadre de la Wiimote suivant comment cette dernière est placée. Il n'est pas forcément rectangle pour les mêmes raisons.
    Enfin en rouge, le point infrarouge émit par le stylet.

    Il nous faut donc déduire, à partir des coordonnées du point [x, y] vues par la Wiimote, les coordonnées du point [x', y'] par rapport à l'écran projeté.
    Pour cela, il faut calculer la transformation entre les dimensions réelles de l'écran projeté (par exemple 1440x900) et celles vues par la Wiimote. Cela se fait par la résolution d'un système d'équations exprimé sous forme d'une matrice tel que décrit dans ce document.
    Des applications dans différents langages de ce document théorique sont disponibles sur cette page du forum developpez.net.
    La première application de l'utilisateur pseudocode en Java décrit la transformation inverse de celle que je doit mettre en œuvre. La seconde en C, de l'utilisateur luxigo donne la transformation dans les deux sens, mais est incomplète. Il a donc fallut que j'écrive à partir de ces exemples, la suite de calcul nécessaire à mes besoins.

    Malheureusement, n'ayant pas parfaitement compris l'algorithme en question, je me suis contenté de l'appliquer dans mon logiciel et je me garderai d'en fournir ici une explication potentiellement erronée. Je laisse cependant libre consultation de mon code si quelqu'un à besoin d'effectuer la même opération que moi à l'avenir.

     

    6. Déplacement du curseur aux coordonnées calculées

    Bien qu'amené à changer dans un futur plus ou moins proche avec l'arrivée de Wayland, les systèmes Linux utilisent actuellement le serveur d'affichage X.org. Afin de déplacer le curseur sur l'écran et de simuler des clics de souris, je me suis servis de la Xlib qui permet d'interagir avec ce serveur d'affichage.
    On peut trouver sur le Web des exemples de codes permettant de bouger le curseur assez facilement, mais pour effectuer des clics de souris cela devient très compliqué. Une façon plus méconnue d'effectuer cette action est d'utiliser une extension de la Xlib nommée XTest. Bien qu'étant une extension, elle est intégrée sur la grande majorité des distributions Linux.
    Grâce à celle-ci, les actions voulus peuvent être faites en appelant une simple fonction.
    Voici un exemple rapide :

    #include &ltX11/extensions/XTest.h&gt
    int X = 192;
    int Y = 42;
    // Création de la connexion au serveur X
    Display *d = XOpenDisplay(NULL);
    // Déplacement du curseur de la souris aux coordonnées X, Y
    XTestFakeMotionEvent(d, -1, X, Y, CurrentTime);
    // Clic de souris (bouton 1)
    XTestFakeButtonEvent(d, 1, True, CurrentTime);
    // Déclic de souris (bouton 1)
    XTestFakeButtonEvent(d, 1, False, CurrentTime);
    // Application des actions
    XSync(d, 0);

    De plus amples explications avec des liens vers d'autres exemples sont accessibles dans la bibliographie à la fin de ce document.

     

    7. Le stylet infrarouge

    Le stylet infrarouge est la seule partie matérielle de ce tableau numérique interactif à construire soit même.
    Le schéma électronique de ce stylet est des plus simple vu qu'il n'est constitué que d'une LED infrarouge, d'un interrupteur bouton-poussoir et d'une pile :

    Schéma électronique d'un stylet infra-rouge

    Seul le choix de la LED est déterminant pour le stylet. Pour ce composant, deux paramètres rentrent en compte :

    • Pour que la tâche de lumière qu'elle projette soit la plus resserrée possible, il faut choisir la LED avec un angle de demi-intensité (noté φ) le plus petit possible. Idéalement il faut qu'il soit au moins inférieur à 30°.
    • L'autre paramètre important est la longueur d'onde de la lumière émise par la LED. Il est préférable qu'elle soit comprise entre 800 et 1000nm.

    Cette LED n'étant pas un laser, il faudra tout de même la maintenir très près du support lors de l'utilisation du stylet pour que la Wiimote puisse voir la tâche de lumière qu'elle émet.

    Enfin, voici un exemple de mon stylet :

    Photo de mon stylet infrarouge

    On y retrouve tous les composant cités précédemment. En dehors du fil que je n'ai pas pu faire loger à l'intérieur, ce stylet est maniable et tiens bien en main.

     

    8. Informations sur le tableau numérique à base de Wiimote

    Voici quelques informations à savoir lorsque l'on veut mettre en place ce type de tableau interactif.
    Premièrement il possède des avantages, mais aussi des inconvénients.
    Avantages :

    • Il est très économique. En dehors du projecteur, il faut compter le prix de la Wiimote (une quarantaine d'euros), ceux des composants du stylet (j'en ai personnellement eu pour 1,75€ pour le bouton-poussoir et la LED infrarouge) et celui de l'adaptateur Bluetooth s'il n'est pas intégré à l'ordinateur que l'on souhaiter utiliser. Ceci est au final largement moins qu'un tableau interactif disponible sur le marché.
    • Installable rapidement

    Inconvénients :

    • Il faut éviter les sources infrarouges parasite. Le soleil par exemple en émet, et s'il est trop puissant, il vient diminuer le contraste entre le fond et le point infrarouge du stylet.
    • Il faut toujours veiller à ne pas se situer entre le point infrarouge et la Wiimote, ce qui oblige à tendre le bras.

    Une fois ces caractéristiques prises en compte, il y a quelques autres choses à savoir pour exploiter au mieux ce tableau interactif. Tout d'abord les angles de vision de la Wiimote sont de 33 degrés horizontalement et 23 degrés verticalement. Il faudra donc veiller à placer la manette à la bonne distance pour qu'elle puisse voir tout l'écran projeté. Pour rappel, il faudra aussi veiller à ne pas se placer entre la manette et l'écran.

     

    9. Résultat final

    Au final, j'ai réussi à concevoir le programme auquel je pensais pour qu'il soit fonctionnel. Le développement de ce logiciel m'aura permis d'apprendre de multiples notions avancées en C (sockets, endianess, threads, mutex, utilisations de bibliothèques diverses, etc). J'ai commenté le plus possible le code afin qu'une autre personne intéressée puisse le comprendre.

    De plus, j'encourage d'autres étudiants à implémenter le concept de tableau numérique pour l'utiliser en classe.

     


     

    Bibliographie

    Concept général :

    Documentations sur la programmation C nécessaires au développement du logiciels :

  • LinuxFr.org : première quinzaine de juin 2018 (Journaux LinuxFR)

    Nonante huitième épisode dans la communication entre les différents intervenants autour du site LinuxFr.org : l’idée est tenir tout le monde au courant de ce qui est fait par les rédacteurs, les admins, les modérateurs, les codeurs, les membres de l’association, etc.

    L’actu résumée ([*] signifie une modification du sujet du courriel) :

    Statistiques

    Du 1er au 15 juin 2018

    • 1528 commentaires publiés (dont 8 masqués depuis) ;
    • 248 tags posés ;
    • 80 comptes ouverts (dont 6 fermés depuis) ;
    • 35 entrées de forums publiées (dont 0 masquée depuis) ;
    • 20 liens publiés (dont 1 masqué depuis) ;
    • 21 dépêches publiées ;
    • 25 journaux publiés (dont 1 masqué depuis) ;
    • 3 entrées nouvelles, 1 corrigée dans le système de suivi ;
    • 1 sondage publié ;
    • 0 pages wiki publiées (dont 0 masquée depuis).

    Listes de diffusion (hors pourriel)

    Liste webmaster@ - [restreint]

    • R.A.S.

    Liste linuxfr-membres@ — [restreint]

    • [membres linuxfr] Bouffe des 20 ans le 28 juin à Paris

    Liste meta@ - [restreint]

    • [Meta] Incident du jour sur SSL/TLS
    • [Meta] Quel avenir pour la tribune ?

    Liste moderateurs@ - [restreint]

    • [Modérateurs] certificat linuxfr expiré
    • [Modérateurs] Incident du jour sur SSL/TLS
    • [Modérateurs] Certificat SSL
    • [Modérateurs] où se trouve les CSS de Linuxfr
    • [Modérateurs] forum - bug pour s'inscrire ?

    Liste prizes@ - [restreint]

    • [Prizes] LinuxFr prizes recap du samedi 9 juin 2018, 13:35:23 (UTC+0200)
    • [Prizes] J'ai gagné un livre!

    Liste redacteurs@ - [public]

    • [Rédacteurs] Incident du jour sur SSL/TLS

    Liste team@ - [restreint]

    • [team linuxfr] Certificat SSL du site linuxfr.org expiré
    • [team linuxfr] Tweet de Laurent Jouanneau (@ljouanneau)
    • [team linuxfr] Incident du jour sur SSL/TLS
    • [team linuxfr] Purge du compte X [*]
    • [team linuxfr] réouverture de compte
    • [team linuxfr] Organisez des événements dans le cadre de la Fête des Possibles, du 15 au 30 septembre 2018

    Liste webmaster@ — [restreint]

    • R.A.S.

    Canal IRC adminsys (résumé)

    • certificat X.509 périmé (encore merci à tous ceux qui l'ont signalé), passage à Let's Encrypt et communication post-incident
    • renouvellement du domaine (encore merci Yann)
    • dernière version de Jessie (8.11) prévu le 23 juin, et ensuite passage en fin de vie
    • question relative à la configuration DMARC de la liste Sympa des modérateurs qui change le From de l'émetteur dans certains cas
    • rachat de GitHub par Microsoft et dépôts LinuxFr.org. Faut-il bouger et pourquoi.
    • Let's Encrypt et HTTP en clair pour le renouvellement ? Voir par exemple la discussion
    • discussion sur les aspects sécurité de l'affichage distant d'images sur la tribune
    • « 20 ans le bel âge pour mourir », ah non ça parle de Yahoo Messenger, pas de nous
    • 20 ans du site et POSS en décembre ?
    • courriels envoyés pour préparer les entretiens des 20 ans
    • peu de présents aux RMLL dans l'équipe. Snif. Me laissez pas tout seul.
    • migration de alpha et main en Jessie
    • travaux en cours pour nettoyer le dépôt git d'admin (avec des fichiers générés par ansible notamment). Sans oublier de finaliser la partie Let's Encrypt…
    • toujours un conteneur à migrer en Jessie, et ensuite trois en Stretch. Et aussi un hôte Trusty à mettre à jour.

    Tribune de rédaction (résumé)

    • idée de dépêche : NetHammer (finalement parue sous forme de lien)
    • avis de grand calme

    Tribune de modération (résumé)

    • peu de présents aux RMLL dans l'équipe. Snif. Me laissez pas tout seul.
    • du spam
    • améliorations de CSS proposées par voxdemonix
    • les admins du site ont des facilités techniques pour traquer les spammeurs et les multis, par rapport aux modérateurs
    • retour des Geek Faeries

    Commits/pushs de code https://github.com/linuxfrorg/

    • (springcleaning) admin-linuxfr.org en cours de conversion vers Ansible
    • Allow users to choose the source for their tribune smileys in prefere…
    • Add a border for missing title on images
    • Fix max height for image on computer screen

    Divers

    Commentaires : voir le flux atom ouvrir dans le navigateur

  • Un an de FreeCAD (en tant que contributeur) (Journaux LinuxFR)

    Il y maintenant un an je commençais une aventure, contribuer a un projet Open Source pour les besoins de l’équipe d'Horizon Computing: FreeCAD.

    Pour rapide mémoire, Horizon est ma société, et nous développons des ordinateurs en mode ouvert ou Open Hardware. La tache est ardu car nous devons faire tomber beaucoup (peut-être trop à notre échelle) de verrou technologiques et légaux.

    Jusqu’à présent nous développions nos ordinateurs avec des logiciels propriétaires (c'est toujours le cas pour certaines parties), et je trouvais sincèrement absurde de faire la promotion de l'Open Hardware en utilisant des outils propriétaires (tout comme faire tourner Linux sur du hardware propriétaire va le devenir). L'usage de ces outils limite drastiquement l'expansion des communautés Open Hardware car leur accessibilité est limité. Nous faisons maintenant partie d'Open Compute, d'Open Power et RISC-V. Ces communautés sont pilotées par des entreprises qui ont beaucoup d'argent et ont mis très longtemps à comprendre l'importance de accessibilité aux outils, ce qui leurs a valu d'ailleurs des volées de bois vert de la part de certains membres qui développent des logiciels libres ou d'autres solutions open hardware.

    Rome ne s'est pas construite en un jour, et je pense que l'on peut prouver que les logiciels libres sont par essence une bonne solution pour concevoir des ordinateurs libres. Mais il faut pour autant les adapter. J'aime utiliser cet exemple, est-ce que le noyau linux se serait développe avec l'usage d'un compilateur propriétaire ? Probablement que non , et je pense que c'est pareil pour l'Open Hardware. Ce mouvement deviendra un succès le jour ou il sera auto suffisant et que nous irons tous dans la même direction. (je pourrai écrire un roman sur le comportement des libristes vis a vis d'OCP et du hardware libre, de leur amour pour les marques propriétaires et les guerres de chapelles que l'Open Hardware engendrent, mais ce n'est pas le propos du jour ca me rappelle linux vs unix et on connait la fin).

    Alors que manque-t-il à FreeCAD et que s'est-il passé durant ma première année de contributeur. La première des choses j'ai beaucoup appris. FreeCAD est un code extra-ordinaire qui utilise un nombre incalculable de technologies auxquelles je tire mon chapeau. Le moteur 3D est basé sur l'excellent OpenCascade, le rendu sur Inventor/Coin3D, et la possibilité de scripter via Python est un plus non négligeable. Le hic, c'est que au final même si le code est bien architecturé, il est énorme, et créer sa première contribution peut sembler au premier abord un sacré challenge.

    Toutefois, le code est développé/maintenu par une petite équipe d'amateurs (c'est un projet sur lequel aucune personne ne travaille à temps plein), qui a besoin de nouveaux contributeurs, et l'accueil qui m'a été fait a été super positif, et j'ai pourtant commencé par un commit de 100k lignes (pas un petit commit).

    Durant cette année, j'ai passé pas mal de temps à comprendre les problèmes de performances du soft et a mettre à jour les bibliothèques de base sur lequel il repose (passage d'OCE 6.7 à OCCT 7.0.0 ou 7.1 en fonction des releases, mise à jour de SMESH, accélération de la lecture des fichiers STEP, et en ce moment migration du moteur de rendu vers le support des VBO OpenGL afin de multiplier par 3 le frame rate).

    Tout cela n'aurait pu se faire sans le support de la communauté FreeCAD que je remercie chaleureusement et qui intègre au fur à mesure ces fonctions dans la version en cours de développement (0.17). Les contributeurs OCP peuvent maintenant traiter et commenter les designs mécaniques avec FreeCAD ce qui n’était pas le cas il y a quelques mois. Le projet RuggedPOD est maintenant entièrement désigné avec FreeCAD !

    Mes prochaines étapes consistent à intégrer un solveur libre (Elmer) en utilisant FreeCAD comme solution de pré et post traitement. Une fois qu'on aura fait tout cela et que la nouvelle version du module PartDesign, je pense que l'on pourra développer l'ensemble des éléments mécaniques d'un serveur et d'un datacenter avec des logiciels libres. Vivement la version 0.18 !

    Tout ca pour vous dire qu'avec de la volonté on peut réussir a changer les choses. Bon soyons honnête il m'a fallu beaucoup de temps pour faire toutes ces modifications dans le code d'autant que cela faisait plus de 15 ans que je n'avais pas fait de 3D, mais c'est comme le vélo.

    Je crois sincèrement que l'avenir de l'Open Hardware passe par le succès de certains logiciels libres, et que les améliorer permettra à une génération d'architecte matériel d'améliorer leur design en collaborant. Alors si vous avez un peu de temps, devenez contributeur FreeCAD ! Et consommez de l'Open Hardware (même chez votre hébergeur préféré), vous aiderez différentes communautés en pleine ébullition à créer le futur de l'informatique ou d'autres secteurs industriels et disposerez de machines beaucoup plus maintenables (plus obsolescence programmée) et dépourvu de backdoor (des qu'on aura tout sur des BIOS libre)

    Lire les commentaires

  • Un petit bot telegram (Journaux LinuxFR)

    Bonne rentrée à tous!

    Pour fêter cela je vous propose mon premier bot telegram:
    https://storebot.me/bot/dictonbot

    Il permet soit de demander le dicton du jour (texte ou .mp3; mp3 fait avec espeak afin que cela soit une authentique voix de robot!), soit de s'y abonner et le recevoir chaque jour à midi (texte seulement). Le dicton est sensé être humoristique 😃

    J'en profite pour savoir si certains d'entre vous ont fait des bots, pour telegram ou autre, et ce que tout le monde en pense.

    Il parait que c'est le nouveau futur :*)

    Lire les commentaires

  • Inverse annonce la sortie de la version 4 de SOGo ! (Dépêches LinuxFR)

    Cette version offre de nouvelles fonctionnalités telles que la prise en charge complète du S/MIME, une nouvelle vue calendrier, une meilleure gestion des événements répétitifs et des sources d’authentification SQL. De plus, SOGo v4 apporte un grand nombre d’améliorations et de correctifs à la version précédente au niveau du protocole Exchange ActiveSync et de l’interface Web.

    SOGo est un collecticiel (groupware) axé sur l’extensibilité et le respect des standards ouverts. Il permet aux utilisateurs Mozilla Thunderbird avec l’extension Lightning, Apple Calendar/Contacts (macOS et iOS) et Microsoft Outlook de collaborer dans un environnement moderne et cohérent. Il propose les composants classiques des collecticiels : carnet d’adresses, gestion de courrier électronique et calendriers partagés. Finalement, SOGo supporte aussi le protocole Exchange ActiveSync pour la synchronisation des appareils Android, iOS, Windows Phone, BlackBerry et même Microsoft Outlook 2013/2016. SOGo est traduit dans trente‐quatre langues.

    SOGo est édité sous licence GPL v2.

    Lire les commentaires