Linux (fr)

  • The MagPi n°7 et 8 distribués gratuitement sur les campus de Caen, Grenoble, Lyon, Troyes et Mâcon ! (Laboratoire Linux SUPINFO)

    En ce début d'année 2014, certain ont pu découvrir que le Père Noel était passé à SUPINFO, principalement à l'attention des laboratoires Linux, Robotique et SL3 mais aussi et surtout à tous les étudiants curieux d'électronique.

    The MagPi est un magazine communautaire anglophone qui a été traduit et édité sous licence Creative Commons BY-NC-SA, permettant ainsi à SUPINFO de l'imprimer et de le diffuser à titre gratuit, en sa qualité d'association loi 1901.

    Les magazines profitent de la même qualité d'impression que le Supinfo Inside, les étudiants des campus sélectionnés découvriront ainsi en version papier comment faire de la rétroingénierie classique, asservir une carte Arduino avec une carte Raspberry Pi (ainsi que les avantages que cela procure), de quoi stimuler leur imagination sur des projets robotiques ou domotiques. La sélection s'est basée sur la réalisation de projets publiés sur les sites des labos. Les magazines restent disponibles en PDF sur le site du MagPi.

    image

    Sophie, notre assistante de direction à Caen, semblait intriguée par le magazine !

    image

  • Espionnage: la FSF deconseille le cloud public, recommande les clouds privés basés sur le libre (Journaux LinuxFR)

    Le journal The Guardian a révélé que la NSA (Agence de Sécurité Nationale des États-Unis) a un accès direct aux systèmes de Google, Facebook, Apple et autres géants de l'Internet, pour espionner les communications qui passent par les États-Unis. John Sullivan, directeur de la Free Software Foundation, conseille d'utiliser des logiciels libres (en cloud privé) plutôt que le cloud public:

    Des intrusions de la vie privée de cette ampleur sont à craindre quand les gens abandonnent leurs données et logiciels locaux pour migrer vers le stockage et les applications en ligne. Les géants come Microsoft, Facebook et Google sont vulnérables aux requêtes du gouvernement exigeant les données des utilisateurs. Pour contrer ce problème, il y a de meilleurs moyens, plus sûrs, de partager des informations en ligne. Les logiciels libres comme GNU MediaGoblin, StatusNet, Diaspora, pump.io, Tahoe-LAFS, FreedomBox et SparkleShare travaillent d'arrache-pied pour créer un monde moins centralisé, un monde dans lequel les utilisateurs maintiennent le contrôle sur leurs données et sur les logiciels qui accèdent à ces données, mais un monde qui est tout aussi pratique et social que son équivalent centralisé.

    MediaGoblin: Publication de media. Similaire à Flickr, YouTube, SoundCloud.
    StatusNet: Micro-blogging. Similaire à Twitter.
    Diaspora, pump.io, Freedombox: Réseau social décentralisé. Similaire à Facebook.
    Tahoe-LAFS, SparkleShare, CmisSync: Synchronisation de fichiers. Similaire à Dropbox.
    Zimbra: Email. Similaire à Gmail/Calendar.

    Lire les commentaires

  • RyDroid Web Proxy (1.0) : outil de capture de sessions Web (Dépêches LinuxFR)

    Pendant l’année scolaire 2016-2017, j’étais en dernière année d’école d’ingénieurs
    (l’ENSICAEN). J’ai donc fait un stage de fin d’études (à Orange, en France), avec le rapport qui va avec. J’ai fait un logiciel libre qui a été publié. En conséquence, il m’a paru logique de publier mon rapport, après avoir enlevé quelques parties (remerciements, présentation du collectif de production, conclusion personnelle, etc.) et fait de petites retouches pour qu’il soit cohérent avec ce nouveau format et la visibilité qui va avec. Cela permet de présenter plus largement ce que j’ai fait, tout en expliquant le pourquoi et comment, ce qui pourrait servir à d’autres personnes.

    Logo de CLIF Web Proxy (nom originel de RyDroid Web Proxy)

    Sommaire

    Le sujet

    Celui qui a été mon tuteur de stage participe activement au développement d'un outil de test de performance à travers le réseau, qui s'appelle CLIF et qui est présenté plus loin dans cet article. Le cas le plus courant est le test pour le web, avec le protocole HTTP et sa version chiffrée HTTPS. Pour faciliter l'usage pour ce cas commun, il faut que créer un scénario de test pour ce dernier soit aisé.

    Il existait déjà une solution : un proxy pouvait être configuré dans le navigateur web pour intercepter les flux réseaux et ainsi enregistrer les informations pertinentes dans le format adéquat (basé sur XML) pour rejouer une session web avec CLIF. Configurer un proxy dans un navigateur web peut être difficile pour certaines personnes ou perçu comme tel. De plus, le proxy ne gère pas le HTTPS (qui est de plus en plus courant), bien qu'il aurait été possible d'en ajouter la gestion, cela aurait nécessité d'ajouter un certificat dans le navigateur web. Mon tuteur voulait un outil plus simple à utiliser et qui gèrent le HTTPS, d'où ce stage.

    Comme CLIF, l'outil réalisé devait être du logiciel libre sous licence GNU LGPL en version 3.

    État de l’art

    Outils de test de charge

    La liste n'est pas exhaustive, mais il y a un article sur Wikipédia en anglais si on en désire une qui cherche à l'être. Cette partie a pour intérêt de présenter rapidement des outils cités plus loin dans l'article présent et de mettre en perspective le programme de mon tuteur de stage.

    Apache JMeter

    JMeter est un logiciel libre de la fondation Apache. Il est très populaire et packagé par au moins Debian et Trisquel GNU/Linux. Pour définir un test de charge, il faut lui soumettre un fichier XML. Il est extensible avec des modules complémentaires.

    Logo de Apache JMeter

    Gatling

    Gatling est un logiciel de test de charge, avec un focus sur les applications web. Il est sous licence Apache 2.0, donc libre. Il est écrit en Scala. Il est packagé par au moins Debian et Trisquel GNU/Linux.

    Selenium

    Selenium est un logiciel pour automatiser la navigation web à travers un navigateur web. Il peut donc servir à faire des tests, mais aussi automatiser des tâches administratives se faisant via le Web. Il est libre via la licence Apache 2.0.

    Tsung

    Tsung est un logiciel de test de charge distribué. Il gère différents protocoles (dont HTTP, XMPP, LDAP, et MQTT). Il est libre sous licence GNU GPL version 2.0. Le langage de programmation utilisé est Erlang. Il prend en entrée un fichier XML. Il est disponible sous forme de paquet dans au moins Trisquel GNU/Linux et Debian.

    Logo de Tsung

    Locust

    Locust a la particularité d'utiliser des scripts en Python pour définir le comportement des utilisateurs virtuels, alors que les autres outils utilisent généralement du XML et/ou une interface graphique. C'est un logiciel libre sous licence "MIT".

    Logo de Locust

    The Grinder

    The Grinder est un framework pour le test de charge. Il est adapté pour le test distribué sur plusieurs machines. Il est libre et écrit en langage Java.

    Taurus

    Taurus a pour but de cacher la complexité des tests fonctionnels et de performance. Il fait cela en étant une enveloppe pour JMeter, Gatling, Locust, Grinder, et Selenium WebDriver. Il prend en entrée un fichier au format YAML. C'est un logiciel libre sous licence Apache 2.0.

    Logo de Taurus

    CLIF

    CLIF est un logiciel libre initié, piloté, et maintenu par celui qui a été mon tuteur de stage (Bruno Dillenseger). C'est un acronyme récursif pour "CLIF is a Load Injection Framework". Ce projet est hébergé par le consortium OW2. Il est écrit dans le langage de programmation Java. Il a une interface en ligne de commande et une interface graphique sous forme de module complémentaire pour Eclipse. Il propose plusieurs manières de définir un test de charge, comme cela est expliqué dans une sous-sous-section (de cet article) partiellement dédiée. Il n'y a pas de paquet Debian, notamment à cause des nombreuses dépendances et d'au moins une dont les sources n'auraient pas été retrouvées.

    Logo de CLIF

    CLIF permet de déployer des injecteurs de requêtes répartis pour mesurer les temps de réponse. Il permet également de déployer des sondes afin de mesurer la consommation des ressources (processeur, réseau, mémoire, disque, etc.). Son environnement de scénario ISAC offre une façon formelle de définir les scénarios sous forme de comportements d'utilisateurs virtuels et d'une spécification du nombre d'utilisateurs virtuels actifs de chaque comportement au cours du temps. CLIF a été spécialement conçu pour être rapidement adaptable à toute sorte de cas de test (un assistant Eclipse permet de définir ses propres modules complémentaires pour intégrer de nouveaux protocoles ou de nouveaux jeux de données), y compris des hauts niveaux de charge (comme des centaines d'injecteurs et des millions d'utilisateurs virtuels). En pratique, CLIF est utilisé pour des tests de tenue en charge, mais également pour des tests fonctionnels, des tests en intégration continue et de la supervision de qualité d'expérience utilisateur, notamment via son module complémentaire pour Jenkins.

    Le code source est sur l'instance GitLab de OW2, à part le module complémentaire pour Jenkins qui est sur GitHub. CLIF est aussi disponible sur la forge historique de OW2 (qui propose des versions compilées).

    Loads et Molotov

    Loads et Molotov sont libres et écrits en langage Python. Ils permettent d'écrire des tests unitaires. Loads est développé et testé sur Python 2.6 et 2.7, tandis que Molotov nécessite Python 3.5 ou plus.

    Logo de Loads et Molotov par Juan Pablo Bravo

    HPE LoadRunner

    HPE LoadRunner est un logiciel privateur de test de charge, qui ne fonctionne complètement que sous Microsoft Windows. Il peut être étendu via des formats d'autres outils (comme JMeter) et des scripts dans différents langages (comme C et Java). Sa première version date de l'an 2000, il est depuis toujours amélioré, ce qu'il lui a permis d'acquérir une place importante dans le domaine du test de charge.

    megaLOAD

    megaLOAD est présenté comme étant une plateforme en ligne de test de charge qui serait facile à utiliser et capable de monter à l'échelle. Il aurait été spécialement créé pour tester les services de type back-end ayant vocation à être très robustes. Il est fait par Erlang Solutions. Il gère HTTP et serait suffisamment extensible pour gérer n'importe quel protocole. Il serait possible de l'utiliser via un navigateur web et/ou une interface de programmation RESTful. Il est disponible sur AWS (Amazon Web Services).

    Siege

    Siege est un outil libre pour tester la capacité de charge des implémentations des protocoles HTTP(S) (version 1.0 et 1.1) et FTP. Il est écrit en langage C et fonctionne sur divers systèmes d'exploitation POSIX (comme GNU/Linux et des BSD récents, mais pas Windows). Il est libre sous la licence GPL en version 3.0.

    Outils de capture d’utilisation Internet

    Différentes organisations proposent des services web pour l'injection de charge. Certaines d'entre elles proposent un outil pour facilement capturer une session d'usage du réseau, ce qui permet ensuite de la rejouer facilement.

    On pourrait naïvement penser que tcpdump, Wireshark, ou Scapy sont de bons candidats sans rien faire. Ce serait vrai si les communications passaient toutes, ou au moins une vaste majorité, en clair sur les réseaux et que cela n'était pas amené à changer. En effet, elles sont de plus en plus chiffrées (avec une accélération depuis 2013 suite aux révélations d'Edward Snowden), ce qui permet de "garantir" (par les mathématiques) la confidentialité de ce qui est chiffré (il y aura toujours un minimum de méta-données non chiffrées). Il faut donc trouver un moyen de contourner le chiffrement quand il y en a, ce que tcpdump, Wireshark, et Scapy ne font pas automatiquement. De plus, ces derniers montrent une quantité de détails techniques inutiles pour l'individu (dans notre contexte) et qui pourraient le perturber (par peur de l'inconnu et/ou difficulté à percevoir ce qui est pertinent).

    NeoLoad

    NeoLoad Recorder est une application qui enregistre un parcours utilisateur fait à travers un proxy. Pour cela, il crée un proxy sur la machine sur laquelle il est exécuté. Ensuite, il génère un certificat X.509 qui va servir à déchiffrer les échanges chiffrés via TLS. Puis, il démarre Firefox dans lequel il faut configurer le proxy et ajouter le certificat si on souhaite enregistrer les communications chiffrées via TLS. Après cela, il n'y a plus qu'à naviguer. Une fois que l'on veut arrêter, il faut penser à enlever le proxy (mais on s'en rendra vite compte si on oublie), et ne plus faire confiance au certificat (ce qui ne sera rappelé par aucune erreur).

    Cette solution technique est problématique si on doit passer par un proxy pour accéder à un réseau sur lequel le site web à tester est accessible. Techniquement, il est écrit en Java. Les données sont enregistrées dans un format inconnu et non trivial.

    Schéma du fonctionnement de NeoLoad Recorder

    HPE StormRunner Load

    HPE StormRunner Load est un service distant pour faire du test de charge et en analyser les résultats. Il est basé sur du logiciel privateur et se manipule via une interface web. Pour faciliter son usage, divers outils (non libres) sont mis à disposition.

    Pour rendre aisé la capture de la navigation web, il propose 2 outils : TruClient Lite et TruClient Standalone. Ils ont pour but de capturer (directement) ce qui se passe dans un navigateur web (donc sans proxy externe et sans certificat pour le HTTPS). TruClient Lite est un module complémentaire pour Chromium (et donc son principal dérivé Google Chrome), qui utilise les paramètres de proxy du navigateur web. TruClient Standalone est un logiciel (fonctionnant uniquement sur Windows) qui peut au choix se baser sur les moteurs de Firefox (Gecko), Chromium, ou Internet Explorer, mais également simuler un mobile ou une tablette (en configurant correctement la résolution du navigateur web et son agent utilisateur), il prend les contrôles sur le proxy du navigateur web. L'absence de contrôle sur le proxy est problématique si on doit passer par un proxy pour quitter un réseau interne, mais il est possible de lui indiquer un proxy après que le script soit généré. Ils enregistrent les clics sur les boutons avec leurs intitulés (même s'ils ne sont pas des liens), et se basent sur l'intitulé des boutons pour naviguer et pas sur les URLs, ce qui est pratique si les références des liens changent. Ils permettent également de rejouer (automatiquement) un script enregistré avec une visualisation graphique, cependant ils sont perdus s'ils essayent de rejouer mais que le texte du bouton n'est pas le même (par exemple à cause de la langue par défaut différente en fonction du navigateur web).

    Schéma du fonctionnement de HP TruClient

    BlazeMeter

    BlazeMeter est une plateforme SaaSS web. Il peut réaliser des tests de charge et montrer des statistiques (en temps réel) qui en résultent. Il propose une API web pour automatiser les tests, par exemple dans le cadre de l'intégration continue (via Jenkins ou un autre outil similaire). Il utilise divers logiciel libres (dont JMeter, Gatling, et Taurus) et gère donc leurs formats de données.

    Pour simplifier les tests web, un outil de capture de session web est proposé, BlazeMeter Proxy Recorder. C'est malheureusement du logiciel privateur. On peut le tester gratuitement pendant 1 mois. Pour l'utiliser, il faut s'inscrire et l'activer. Ensuite, il faut aller dans son interface, ce qui crée un proxy (sans intervention du testeur ou de la testeuse) et un certificat X.509 (souvent appelé d'une manière réductrice certificat TLS). Pour enregistrer ce que l'on fait via un client web, il faut activer le proxy (via un simple bouton) et configurer ce dernier dans notre client web. S'il l'on souhaite que les communications chiffrées soient enregistrées, il faut ajouter un certificat qui va permettre au proxy de déchiffrer avec une de ses clés privées (au lieu d'une clé privée du service web consulté). Au fur et à mesure de la navigation (via le proxy), l'interface graphique de BlazeMeter Recorder montre ce qu'il a capturé. Pour finaliser une session, il suffit de cliquer sur un bouton (de l'interface web). On peut ensuite avoir le résultat sous divers formes (URL pour BlazeMeter, fichier JMeter, fichier pour Selenium WebDriver, ou fichier pour Taurus).

    Schéma du fonctionnement de BlazeMeter Recorder

    SOASTA Cloud Test

    SOASTA Cloud Test est un SaaSS web pour le test de charge et l'analyse des données (en temps réel) qui en sont issues. Parmi les analyses qu'il propose, il a l'originalité de proposer une comparaison du temps de chargement et du revenu généré sur une période. Il permet de choisir où seront géographiquement les utilisateurs virtuels d'un test. Il propose une interface en 3 dimensions avec les flux réseaux qu'il génère sur une carte de la Terre, dont l'intérêt est probablement discutable, mais cela peut être pertinent pour se faire payer le service par un·e commercial·e. Il peut importer des fichiers JMeter.

    Contrairement à certains de ses concurrents, son outil de capture d'usage du réseau fonctionne sur plusieurs protocoles Internet (temps des connexions TCP, DNS, TLS, HTTP, etc.). C'est une machine virtuelle (sous CentOS) qui fonctionne avec VMware Player, ce qui est très lourd (en termes de puissance de calcul, de mémoire vive, et de place dans la mémoire persistante puisque le disque de la machine virtuelle fait 15Go). Ce choix technique le réserve à des informaticien·ne·s ayant du temps ou des personnes ne voulant pas se limiter au Web.

    La réalisation du projet

    Les outils utilisés

    Les outils pour le développement lui-même

    • Système d'exploitation : Debian GNU/Linux 9 "Stretch" (qui devenu stable pendant mon stage, inclut PHP 7, et est vastement utilisé)
    • Éditeur de code : GNU Emacs (parce qu'il ne nécessite pas de souris et qu'il est beaucoup plus léger qu'un environnement de développement intégré)
    • Langage de programmation : PHP 7 (qui a une librairie standard fourni pour le Web, permet la déclaration de type sur tous les types non objets, et a des avantages de facilité d'installation pour les applications se basant dessus comme cela est expliqué dans la partie qui est dédiée à ce sujet)

    Les outils pour gérer le développement

    • Gestionnaire de versions : git ("le gestionnaire de contenu stupide" (d’après son manuel) est un logiciel libre de gestion de versions décentralisé, libre, performant, et populaire)
    • Forges logicielles :
      • tuleap (une forge logicielle, comprenant des outils élaborés de gestion de projets et des possibilités de gestion fine des droits)
      • GitLab (de plus en plus utilisé, pensé avant tout pour les développeurs et développeuses, et je l'utilise pour des projets personnels)

    Les outils pour les tests

    Les outils « annexes »

    Le résultat

    Schéma du fonctionnement de mon proxy en PHP

    Comparaison avec un proxy classique

    Un proxy classique est légèrement plus dur à utiliser. En effet, il faut que l'utilisateur ou utilisatrice configure un proxy. De plus, pour les échanges chiffrés, il faut ajouter un certificat.

    Néanmoins, un proxy classique a un énorme avantage, il est techniquement plus simple, puisqu'il fait moins de choses, et est donc bien plus performant. En effet, le proxy que j'ai réalisé doit détecter puis analyser entre autres le HTML et le CSS, et enfin potentiellement les modifier, ce qui nécessite une puissance de calcul non négligeable si plusieurs agents l'utilisent en même temps.

    « Proxifier » une URL

    Mon proxy n'est pas un proxy "classique", il change les URLs pour qu'elles pointent toutes vers lui, c'est ce que l'on peut nommer la "proxification" d'URL. En simplifiant, cela revient à ajouter un préfixe à l'URL. Techniquement le préfixe est une référence du proxy (nom de domaine, adresse IP, ou nom purement symbolique comme localhost), puis la page qui "proxifie", et enfin le ou les différents paramètres GET à passer à la page.

    Il y a un paramètre obligatoire qui est l'URL de la page à "proxifier". Celui-ci peut contenir des caractères illégaux comme valeur de paramètre GET (comme un point d'interrogation "?" ou une esperluette "&"), il faut donc encoder ce paramètre au moment de la "proxification", et le décoder au moment de son usage. Cela est fait avec les fonctions PHP urlencode et urldecode (pour lesquels il existe des équivalents en JavaScript).

    Il y a aussi 2 paramètres GET facultatifs. Ils ont pour nom proxy-url et proxy-port et permettent d'indiquer à mon proxy d'utiliser un proxy classique (en spécifiant à minima une URL et potentiellement un numéro de port). Il y a d'autres moyens pour cela, mais ce moyen est prioritaire sur les autres. Si au moins un est indiqué, il faut le(s) propager à toutes les URLs à "proxifier".

    Récupérer une ressource Web

    Un proxy réseau sert d’intermédiaire pour récupérer une ressource. La problématique est banale, mais nécessite néanmoins un peu de temps pour être gérée correctement.

    La première approche que j'ai utilisée est d'utiliser la fonction file_get_contents. C'est une fonction de haut niveau qui prend en entrée obligatoire le chemin vers une ressource (du système de fichiers ou via le Web), et retourne le contenu si elle a réussi à l'obtenir. C'est très facile d'emploi, cependant elle a un gros manque : elle ne récupère pas les en-têtes HTTP, or elles peuvent être pertinentes pour rejouer une session web (ce qui pour rappel est la finalité indirecte de mon proxy). Il fallait donc proposer un autre moyen activé par défaut si disponible.

    Il y a une commande et une bibliothèque associée pour récupérer (entre autres) une ressource sur le Web qui est très connu et a de nombreuses options : il s'agit de curl. C'est libre et existe depuis longtemps (la première version date de 1997), ce qui explique au moins en partie qu'il y ait des fonctions pour utiliser curl dans la librairie standard de PHP. Dans les archives officielles de Debian, il est dans le paquet php-curl qui n'est pas une dépendance du paquet php, probablement pour mettre une installation minimaliste de PHP quand toute la librairie standard du langage n'est pas nécessaire.

    Une application web ne se sert pas nécessairement que de l'URL pour définir (et potentiellement générer) la ressource à envoyer. En effet, une ou des en-têtes HTTP de la requête peuvent être utilisées. Il a donc fallu faire suivre les en-têtes du client web envoyés au proxy au service web "proxifié". Cela a pu être fait avec les 2 méthodes de récupération de ressources.

    Certaines URLs commencent par //, ce qui indique qu'il faut deviner quel protocole utiliser. Le moyen employé pour gérer ce cas est de faire d'abord une requête en HTTPS (la version sécurisée de HTTP), puis renvoyer la réponse si elle est non nulle, sinon renvoyer la réponse de la requête en HTTP.

    Mon proxy peut nécessiter de passer par un proxy réseau non transparent pour accéder à Internet ou un autre réseau IP. C'est le cas dans un nombre non négligeables d'organisations, or certaines applications faites en interne peuvent n'être disponibles qu'en externe et le Web regorge d'exemples pour tester mon proxy. Il fallait donc que mon proxy puisse récupérer une ressource en passant par un proxy réseau non transparent. Cela a été implémenté avec les 2 méthodes de récupération de ressources et il y a plusieurs manières de configurer un proxy (paramètres HTTP GET, cookies, et fichiers INI).

    La gestion du HTML

    Il faut "proxifier" chaque URL d'un document HTML. Le HTML se manipule facilement via DOM et peut être parcouru avec XPath. Il parait donc assez simple de gérer le HTML. Ça l'est… dans la majorité des cas, mais quelques cas rares compliquent les choses.

    Dans les cas triviaux, on peut citer (avec l'expression XPath) : des liens avec a@href, des images avec img@src, les scripts avec script@src, les frames avec frame@src, des vidéos avec video@src, et d'autres. Mais comme nous allons le voir, le HTML est plus compliqué que cela.

    Démarrons avec un cas méconnu si on a appris le HTML récemment, car notoirement obsolète : l'attribut background. Il permet de définir un fond avec l'URL d'une image pour un élément HTML. Pour séparer la structure de la forme, il faudrait utiliser du CSS. Mais il reste de veilles pages web et des personnes n'ayant pas mis à jour leurs connaissances, il a donc fallu gérer ce cas. Cet attribut n'est valide que sur //html/body, mais en pratique certains sites web l'utilisent sur d'autres éléments (comme http://www.volonte-d.com/) et au moins Firefox prend en compte ce cas non standard, qu'il a fallu gérer.

    Poursuivons avec un cas inverse, que l'on ne connait bien que si on a des connaissances à jour : les images ! En effet, il y avait un temps où il y avait uniquement img@src. Cependant pour optimiser la bande passante et avoir une image matricielle d'une taille adaptée, il est maintenant possible de proposer plusieurs URLs pour différentes tailles et formats. La balise img peut maintenant avoir un attribut srcset, qui contient une ou plusieurs URLs séparées par des virgules et avec des indications de la qualité (par exemple <img srcset="img1.png 1x, img2.png 2x" />). Il y a également la balise picture qui peut contenir une ou plusieurs balises source qui peuvent avoir un attribut src ou srcset (//html/body/picture/source@srcset a la même syntaxe que //html/body/img@src).

    La naïveté peut laisser penser que les liens sont triviaux à gérer, c'est presque le cas. Les liens commençant par http:// et https:// sont les plus courants et il faut les "proxifier", mais il y a d'autres cas. Tout d'abord, il n'y a pas que HTTP et HTTPS, il y a d'autres protocoles dont il peut y avoir des références sur le Web et qui ne sont pas gérés par mon proxy, le plus courant étant probablement l'historique FTP (File Transfer Protocol). De plus, il y a des liens sans protocoles pour l'attribut href. En effet, il y a des liens d'actions (qui ne doivent pas être "proxifiés"), pour le courriel avec mailto:, pour le téléphone avec tel: (défini dans la RFC 3966), pour le JavaScript avec javascript: (malgré qu'il y ait l'attribut facultatif onclick et un événement associé en DOM 2), et pour une ressource d'un réseau pair-à-pair avec "magnet:". Il y a également des liens avec un protocole implicite ! Ils commencent par // et les clients web les remplacent par https:// ou http:// ou essayent l'un puis l'autre, il faut donc les "proxifier".

    Rediriger une page web peut se faire via HTTP, mais aussi en HTML. L'intérêt de la méthode en HTML est de pouvoir rediriger après un certain temps (en secondes) et potentiellement uniquement s'il n'y a pas de support JavaScript (en utilisant la balise noscript pour faire cette condition). Cela se fait avec une balise meta dans //html/head (et sans autre parent) en indiquant un temps et potentiellement une URL (par exemple <meta http-equiv="refresh" content="5" /> ou <meta http-equiv="refresh" content="0; url=https://example.net/" />). Il faut donc chercher ce genre de balise (par exemple avec /html/head/meta[lower-case(@http-equiv)='refresh' and contains(lower-case(@content), 'url=')] en XPath 2.0), puis extraire l'URL, ensuite la "proxifier", et enfin changer la valeur de l'attribut tout en conservant le temps.

    Pour utiliser du CSS dans du HTML, il y a plusieurs possibilités. La méthode la plus utilisée et recommandée est de faire référence à un ou plusieurs fichiers via une balise meta avec un attribut rel avec la valeur stylesheet en indiquant l'URL comme valeur de l'attribut href. On peut également vouloir inclure du CSS dans le HTML, ce qui est une mauvaise pratique, mais elle est toujours permise par les navigateurs web. Il y a 2 moyens pour cela : la balise style (/html//style[not(@type) or lower-case(@type)='text/css'] en XPath 2.0) et l'attribut style (/html/body[string(@style)] | /html/body//*[string(@style)]). Il faut donc récupérer le CSS puis le "proxifier" et ensuite mettre la version "proxifiée" dans la balise.

    La gestion du CSS

    Je n'y avais pas pensé au début, mais il peut y avoir des URLs dans du CSS. Elles peuvent par exemple servir pour définir un fond avec une image, inclure un autre fichier CSS, ou importer une police d'écriture
    (depuis CSS3 avec @font-face). Puisque le CSS sert pour la mise en page, il n'est pas négligeable, et a donc du être géré.

    J'ai identifié 2 situations où des URLs sont utilisées dans du CSS. La première et la plus courante est avec la "fonction" url en tant que valeur d'une propriété (par exemple background-image: url(image.png);) Le paramètre peut contenir des espaces avant et après. De plus, il peut être entouré d'un séparateur (soit un guillemet simple soit un double guillemet, heureusement que les formes valides en ASCII sont prises en compte). Le deuxième cas est avec l'instruction @import. Elle peut prendre directement une URL (avec les mêmes séparateurs que la "fonction" url) (par exemple @import "style.css";) ou via la "fonction" url (par exemple @import url(style1.css);).

    Même avec la version 7 de PHP (une version récente d'un langage de programmation orienté web), il n'y a pas de manipulateur lexical pour CSS dans la bibliothèque standard. Plutôt que d'ajouter une dépendance potentiellement non maintenue sur le long terme, j'ai écrit du code pour mon cas particulier. Cela a été motivé par le fait que CSS continue d'évoluer et qu'une avancée de ce dernier pourrait casser le fonctionnement d'un analyseur lexical. Néanmoins mon code souffre d'une limitation : il analyse le CSS ligne par ligne, or la valeur d'une propriété peut être définie sur plusieurs lignes (mais c'est peu courant notamment avec l'usage de programmes pour réduire la taille d'un fichier CSS comme clean-css et YUI Compressor). De plus, mon code ne "proxifie" pas toutes les URLs sur certaines lignes longues pour une raison inconnue. Un analyseur syntaxique de CSS pourrait être utilisé pour "proxifier" toutes les URLs (puisque mon code ne gère pas tous les cas), comme PHP-CSS-Parser de sabberworm, cssparser de Intekhab Rizvi, ou celui de Hord (pour lequel Debian a un paquet). Une option pourrait être ajoutée pour désactiver l'analyseur syntaxique au profit de mon code s'il venait à émettre une erreur fatale à cause d'un cas non géré (potentiellement nouveau) de CSS ou d'une approche moins laxiste que les navigateurs web (qui ont tendance à vouloir gérer à tout prix du code même non valide).

    La gestion du HTTP

    Hormis la ressource demandée par une requête HTTP, il peut y avoir au moins une URL pertinente à "proxifier" (mais cette fois à la réception d'une requête et pas en modifiant préalablement les éléments pouvant en engendrer). Un cas a été identifié : l'en-tête Location. Elle permet d'indiquer une nouvelle URL pour une ressource, expliqué autrement elle sert pour faire une redirection. C'est trivial à gérer si on a déjà le nécessaire pour "proxifier" une URL. En effet, chaque champ d'une requête a un intitulé et une valeur séparée par ":" et sur une seule ligne. C'est donc très simple à analyser et par extension de créer une structure de données pour le HTTP.

    La gestion du HTTP ne s'arrête néanmoins pas là. En effet, un serveur web répond à des requêtes HTTP, or le but de mon stage (et du projet qui en découle) est de rejouer une session web. Il faut donc à minima enregistrer les URLs demandées en extrayant chacune du paramètre GET correspondant. De plus, un serveur web ou une application peuvent répondre différemment en fonction des en-têtes HTTP (heureusement sinon aucun logiciel ne les utiliserait et elles seraient donc inutiles). Il y a donc un intérêt potentiel à les stocker (pour pouvoir reproduire exactement une session web) et en enlever certaines (que l'on peut juger superflues). Il a donc été fait en sorte de les enregistrer et des options ont été faites pour en enlever certaines.

    Gérer les formulaires Web

    Les formulaires web représentent un cas spécial. On pourrait naïvement penser que ce n'est qu'une question de HTML. Mais c'est légèrement plus compliqué que cela.

    Pour les formulaires qui utilisent (implicitement ou explicitement) la méthode HTTP GET (/html/body//form[not(@action) or (string(@action) and lower-case('@method')='get') or not(@method))] en XPath 2.0), il s'agit purement de HTML. Les paramètres GET potentiellement présents dans l'URL de l'attribut form@action (qui définit à quelle URL envoyer les données du formulaire) sont ignorés, en effet ce sont les champs du formulaire qui sont passés en paramètres GET. Il faut donc créer un champ dans le formulaire (avec la balise input) pour l'URL "proxifiée" et le cacher (ce qui se fait en créant un attribut type et lui attribuant la valeur hidden).

    Pour les formulaires utilisant la méthode HTTP POST (c'est l'unique autre possibilité), il faut "proxifier" l'URL de l'attribut action s'il y en a un. Une fois la requête POST reçu sur mon proxy, il faut détecter que c'est une méthode POST pour : la renvoyer en méthode POST au service "proxifié" (par défaut c'est la méthode GET qui est utilisée), ne pas essayer de "proxifier" le contenu, et ne pas renvoyer l'en-tête HTTP Content-Length (défini dans la section 14.13 de la RFC 2616) (ce qui peut faire échouer l'appel PHP à curl, probablement dans le cas où PHP ait encodé différemment le contenu et donc potentiellement changé la taille). Bien entendu, il faut aussi penser à enregistrer ces paramètres POST.

    La gestion du JavaScript

    Je n'y avais pas pensé au début (alors que c'est évident quand on fait du web en 2017), mais le JavaScript peut être source de requêtes web. Il faut "proxifier" les URLs de ces requêtes, bien entendu avant qu'elles n'aient lieu. La première idée qui pourrait venir à l'esprit serait d'utiliser un analyseur syntaxique de JavaScript, ce qui serait très lourd et il en existe à priori qu'en C et C++ (comme V8 de Google qui est libre) (mais il est possible d'appeler des binaires issus de ces langages avec PHP). Heureusement il n'y a pas de moyen de faire des requêtes avec le langage uniquement (c'est-à-dire avec des mots-clés de ce dernier), il faut en effet utiliser la bibliothèque standard du JavaScript. En JavaScript, une fonction peut être redéfinie sans erreur, y compris celles de la bibliothèque standard, c'est considéré comme dangereux (à juste titre) par certains, mais cela peut être fort utile dans de rares cas, comme celui présentement décrit.

    2 cas de fonctions à surcharger pour "proxifier" des URLs ont été identifiés et gérés. Dans chaque cas, il faut garder en mémoire la fonction actuelle (peut être qu'un autre script a déjà changé le comportement de base de la fonction), puis créer une nouvelle fonction qui "proxifie" le ou les arguments contenant potentiellement une ou plusieurs URLs, et enfin appeler la fonction à "proxifier" avec les arguments potentiellement modifiés, tout en retournant son résultat si elle en retourne un. Il ne reste ensuite plus qu'à surcharger, en donnant le même nom pour une fonction ou en modifiant le prototype de la classe pour une méthode d'instance (en effet le JavaScript a un système de classe par prototype qui diffère du modèle traditionnel présent par exemple en PHP et Java). Le terme "fonction" doit ici être compris comme une fonction en C ou en PHP, ce qui ne doit pas être confondu avec la notion de fonction en JavaScript, car celle-ci est bien plus large (les constructeurs et les méthodes sont aussi des fonctions et d'ailleurs défini avec le même mot-clé function).

    Le premier cas est facile à deviner, il s'agit de la fonction à laquelle on passe une URL pour une requête AJAX. C'est l'abréviation de "Asynchronous JavaScript and XML" et désigne un moyen de faire des requêtes synchrones ou asynchrones avec le langage JavaScript. Pour cela, il faut créer un objet de classe XMLHttpRequest (on passe ici sous silence partiel le cas de veilles versions d'Internet Explorer de Microsoft), ensuite définir un comportement (sous forme de fonction) pour le changement d'état (envoyé, reçu, etc.) puis utiliser sa méthode open, et enfin envoyer la requête avec la méthode send. Il suffit de "proxifier" le deuxième argument de la méthode open (le premier étant pour la méthode HTTP).

    Le second cas est moins commun et je ne soupçonnais pas son existence. Il s'agit de l'inclusion dynamique (en JavaScript) de balise script avec un attribut src existant et avec une valeur non nulle. Cela déclenche la récupération du script (grâce à son URL issue de l'attribut src), puis l'exécute (ce qui permet d'éviter la fonction eval). Un élément DOM a une méthode setAttribute, il faut donc la "proxifier" quand elle est appelée sur une balise script et ne "proxifier" le second argument (qui correspond à la valeur de l'attribut) que quand le premier argument vaut (en étant insensible à la casse) src (puisque cette balise peut avoir d'autres attributs comme type).

    La configuration

    Un certain nombre de choses est configurable. Il y a 4 catégories : le proxy pour faire des requêtes (une URL et un numéro de port), la capture de session (enregistrer ou pas, en-têtes HTTP à garder, etc.), le journal d'erreurs et d'avertissements (emplacement en tant que fichier, est-il publique ou non, etc.), et l'interface graphique (montrer des aides au débogage ou pas, afficher certains éléments facultatifs ou pas, etc.).

    La configuration se fait via plusieurs sources et sous forme de cascade. En effet, une source peut avoir une valeur indéfinie, mais une source de moindre priorité peut avoir une valeur définie. De plus, certaines sources ne doivent pas pouvoir définir des valeurs pour certaines propriétés. Par exemple, une source venant du client web ne doit pas être en mesure de définir le chemin d'enregistrement du fichier journal (puisqu'il pourrait s'en servir pour écrire un fichier utilisé par une autre application). Pour configurer au niveau du serveur, il faut utiliser un ou plusieurs fichiers INI.

    Les différentes sources de la plus prioritaire à celle qui l'est le moins est :

    • les paramètres GET dans l'URL
    • les cookies HTTP
    • la session PHP
    • un fichier INI spécifique à une catégorie dans le dossier de l'application
    • un fichier INI général pour toutes les catégories dans le dossier de l'application
    • un fichier INI général pour toutes les catégories dans un dossier système
    • les valeurs par défaut (qui sont codées en dur)
    Exemple de configuration (au format INI)
    # Une ligne commençant par un croisillon "#" est un commentaire.
    # Le dièse "♯" ne marche pas.
    
    # Une section aurait pu être utilisée.
    proxy-url=https://proxy
    proxy-port=80
    
    [session-captured]
    save-session=true
    save-cookies=false

    Enregistrement des données

    À chaque fois qu'une ressource est récupérée par le proxy, celui-ci doit pouvoir enregistrer la demande. L'enregistrement se fait dans le format XML, pour sa manipulation aisée (notamment via DOM, XPath, et XSLT), les nombreuses bibliothèques le gérant, le fait qu'il soit standardisé, et qu'il ne demande pas un serveur de gestion de bases de données. Néanmoins, l'enregistrement en XML est "isolé", de sorte qu'il soit facile (en ajoutant le code nécessaire) d'enregistrer dans un autre format (comme le JSON) ou avec un système de base de données (qui ajouterait une dépendance et une lourdeur) et d'ajouter une option pour choisir le format.

    Un client web peut faire plusieurs requêtes simultanées (notamment pour réduire la latence avec HTTP 1). Or cela peut provoquer une écriture simultanée de nouveaux enregistrements, ce qui est presque certain de résulter en un fichier incorrect. Il a donc fallu mettre en place un verrou pour qu'un fichier d'enregistrement ne puisse être utilisé que pour un enregistrement à la fois. Cela a été fait avec la fonction flock (qui se base sur la fonction C du même nom). La mise en place et la gestion du verrou est dans une classe abstraite qui pourrait être réutilisée pour un autre format de fichier.

    Le proxy était à la base mono-utilisateur. En effet, toutes les données enregistrées étaient nécessairement dans un seul et même fichier. Pour que chaque utilisateur/utilisatrice n'ait pas à installer le proxy, il fallait qu'il soit mutualisable et donc capable de gérer plusieurs personnes. Plutôt qu'un processus de création d'un compte (qui aurait été lourd à utiliser et implémenter), un système d'identifiant de session a été mis en place. Concrètement une personne qui demande à créer une session d'enregistrement se voit retourner un identifiant textuel sous forme de cookie HTTP. Cet identifiant est un nombre pseudo-aléatoire (puisqu'il n'y a pas de réel aléatoire en informatique) obtenu avec une fonction réputée sûre pour la cryptographie (donc imprédictible) (dans mon cas la fonction random_bytes de PHP), ce qui permet de s'assurer que l'on ne puisse pas prédire l'identifiant des autres utilisateurs et utilisatrices. L'identifiant est utilisé comme une partie du nom de fichier, or le nom du fichier aurait été très grand avec la valeur en décimale et illisible avec la valeur en ASCII ou unicode, il est donc le résultat d'une fonction qui prend en entrée le nombre aléatoire et retourne une valeur en hexadécimale. La fonction de hashage SHA-512 a été utilisée, car elle a l'intérêt de créer très peu de collisions (2 valeurs d'entrée ayant la même valeur de sortie) et peut compliquer une attaque s'il venait à être découvert que la fonction n'est pas cryptographiquement sûr (puisqu'une fonction de hashage est censée ne pas avoir de fonction inverse).

    À tout cela, il manquait un élément clé. En effet, les données sont enregistrées pour rejouer un "session web", ce qui nécessite d'enregistrer des éléments techniques, mais également la temporalité de ceux-ci. Pour ce faire un timestamp POSIX (c'est-à-dire le nombre de secondes depuis le premier janvier 1970) est enregistré pour chaque requête. Ce format a l'avantage d'être simple et d'être très courant. Néanmoins la seconde (au format entier) n'est pas une unité très précise, puisqu'un client web sur un ordinateur moderne met moins d'une seconde pour demander différents éléments d'une page web, donc une fonction qui renvoie un timestamp avec les micro-secondes a été utilisée (il s'agit en l'occurrence de la fonction microtime).

    Conversion des données

    Les données sont enregistrées dans un format de données en XML. J'ai moi-même inventé ce format qui est simple et reflète la manière dont les données sont manipulées par le proxy. Cependant les données ne sont pas enregistrées pour un usage interne au proxy, mais pour être données en entrée d'un programme de test de performance. Puisque mon tuteur travaille sur CLIF, c'est pour cet outil qu'il était nécessaire (dans le cadre du stage) de proposer un moyen de faire une conversion. Cependant il n'y aurait aucun problème technique à convertir aussi pour d'autres outils similaires.

    CLIF peut jouer un scénario de test avec du code Java (un langage de programmation très répandu) ou avec des données en XML pour ISAC (qui est un jeu de mot recursif : ISAC is a Scenario Architecture for CLIF). Un moyen de convertir pour le format d'ISAC est de loin ce qui est le plus simple et ne pose aucun problème de limitation dans ce cas (il est possible de coder des comportements plus complexes en Java). C'est donc ce format qui a été choisi.

    Convertir un XML en un autre XML est une volonté courante. La structuration de ce format permet d'envisager facilement de répondre à cette volonté, et un langage est même dédié à cela : XSLT. La conversion est presque entièrement faite en XSLT (en moins de 300 lignes de codes), malgré des différences non négligeables (notamment la manière d'enregistrer les en-têtes HTTP). Cela a été fait en utilisant la version 1.0 du langage XSLT, car la version 2.0 apporte très peu et n'est à priori gérée que par 2 implémentations libres (Saxon-B XSLT et Saxon-HE XSLT).

    Le seul élément que je n'ai pas réussi à convertir avec XSLT est le temps. En effet, mon proxy enregistre le timestamp de chaque requête alors qu'ISAC a besoin du temps entre chaque requête. Il faut donc vérifier pour chaque requête qu'il y a en une suivante (ou précédente), puis faire la soustraction des timestamp, pour ensuite ajouter un élément entre les 2 indiquant le temps qui les sépare. Il a donc fallu faire un script, à appeler avant la conversion XSLT, pour ajouter cette pause.

    L'exécution du script et l'appel de la conversion XSLT sont faits en JavaScript sur le client web. L'opération est presque instantanée avec un ordinateur moderne, néanmoins c'est très dépendant de l'ampleur des données à convertir. L'avantage que ce soit le client web qui fasse l'opération est que le serveur ne nécessite pas les ressources pour cela.

    Exemple de données enregistrées par mon proxy
    <?xml version="1.0" encoding="UTF-8"?>
    <session>
      <resource>
        <url value="https://www.w3.org/XML/" />
      </resource>
    
      <pause value="5003.14" unit="ms" />
    
      <resource>
        <url value="http://clif.ow2.org/" />
        <method value="GET" />
        <timeRequest  value="1497965627.5526"
                      unit="ms" type="unix-timestamp" />
        <timeResponse value="1497965627.6498"
                      unit="ms" type="unix-timestamp" />
        <headers from="client">
          <header key="User-Agent"
                  value="Mozilla/5.0 (X11; i686) Firefox/45" />
          <header key="Accept-Language" value="en-us"/>
          <header key="Connection" value="keep-alive" />
          <header key="If-Modified-Since"
                  value="Wed, 28 Oct 2015 15:47:33 GMT" />
          <header key="Cache-Control" value="max-age=0" />
        </headers>
        <proxy url="https://proxy" port="80" />
      </resource>
    </session>
    Exemple de données converties pour ISAC de CLIF
    <?xml version="1.0" encoding="utf-8"?>
    <scenario>
      <behaviors>
        <plugins>
          <use id="replayHttp" name="HttpInjector" />
          <use id="replayTimer" name="ConstantTimer" />
        </plugins>
    
        <behavior id="session">
          <sample use="replayHttp">
            <params>
              <param name="uri"
                     value="https://www.w3.org/XML/" />
            </params>
          </sample>
    
          <timer use="replayTimer" name="sleep">
            <params>
              <param name="duration_arg" value="5003" />
            </params>
          </timer>
    
          <sample use="replayHttp" name="get">
            <params>
              <param name="uri"
                     value="http://clif.ow2.org/" />
              <param name="headers" value="header=User-Agent|value=Mozilla/5.0 (X11\; i686) Firefox/45|;header=Accept-Language|value=en-us|;header=Connection|value=keep-alive|;header=If-Modified-Since|value=Wed, 28 Oct 2015 15:47:33 GMT|;header=Cache-Control|value=max-age=0|;" />
              <param name="proxyhost" value="https://proxy" />
              <param name="proxyport" value="80" />
            </params>
          </sample>
        </behavior>
      </behaviors>
    </scenario>

    L’API Web

    Une API (Application Programming Interface) web basique a été faite. Elle ne s'appuie ni sur XML ni sur JSON (qui sont beaucoup utilisés pour faire une API web). En effet, elle utilise les paramètres GET (en entrée uniquement), les cookies HTTP (en entrée et en sortie), et le contenu HTTP (en sortie uniquement). Elle permet de "proxifier" une ressource, gérer une session (créer, détruire, et en recréer une qui écrase l'actuelle), obtenir les données de la session dans mon format, et d'obtenir la configuration au format HTML (il pourrait être utile de faire de même en JSON et/ou XML). Elle est utilisée par l'application, mais elle pourrait être utilisée par une application tierce. Elle est plus amplement documentée dans un fichier qui est converti en page web et accessible depuis le menu du proxy.

    L’interface graphique

    L'interface graphique est visuellement rudimentaire, mais elle est facile à utiliser et est adaptée à un écran de mobile. La page d'accueil permet de gérer une session (en utilisant l'API web qui peut rediriger vers la page précédente), d'être envoyé sur le formulaire pour "proxifier", de télécharger les données de la session (s'il y en a), et de gérer la configuration.

    Il est possible de télécharger les données de la session telles qu'elles sont enregistées par mon proxy. Il est également possible de télécharger les données converties. La conversion est pour l'instant possible uniquement pour CLIF, mais il serait facile d'ajouter le nécessaire dans l'interface graphique pour d'autres outils similaires. Pour récupérer les données converties, il y a un formulaire pré-rempli avec les données de mon proxy (récupérées via l'API grâce à une requête AJAX) qui fait la conversion dans le format sélectionné au moindre changement dans les données d'entrée dans le client web (pour éviter que le serveur ait à faire ce traitement) et en utilisant "uniquement" du JavaScript (mais le JavaScript peut utiliser du XSLT).

    La configuration se fait via des formulaires. Actuellement, ils sont gérés uniquement en JavaScript, mais il serait possible d'ajouter une gestion sans JavaScript. L'avantage de passer par JavaScript est de pouvoir afficher la nouvelle configuration effective sans recharger la page et sans soumettre le formulaire pour les cases à cocher (en positionnant des cookies dans ce langage et en utilisant des requêtes AJAX avec l'API web pour la configuration).

    L’installation facile

    Il n'y avait aucune certitude que quelqu'un continue régulièrement de développer l'outil, il fallait donc considérer par précaution qu'il n'y aurait que moi qui en aurait une bonne connaissance technique. Il faut donc que l'installation soit facile, même sans moi, pour éviter que ce que j'ai créé tombe dans l'oubli.

    La partie cliente nécessite un navigateur web avec JavaScript, comme Mozilla Firefox ou Chromium, ce qui est très simple à installer et très courant. La partie serveur est faite en PHP (dans sa version 7), qui est très courant pour faire un site web ou une application web. C'est un langage de script sans compilation, il suffit donc d'appeler un script PHP avec un interpréteur adéquat (ainsi que la bibliothèque standard) pour l'exécuter avec succès. Pour appeler automatiquement les scripts via le web, il faut un serveur web gérant CGI (Common Gateway Interface). Il y a pour cela Apache qui est libre (sous licence Apache 2.0), fonctionne sur les principaux systèmes utilisés pour faire serveur (GNU/Linux, les BSD, Microsoft Windows, et Apple macOS), packagé par les principales distributions GNU/Linux (notamment Debian, RHEL/CentOS, et Ubuntu) et est le logiciel faisant serveur web le plus utilisé au monde. Cela n'a pas été testé, mais il ne devrait pas y avoir de problème avec nginx qui est le principal concurrent libre. Les pré-requis pour l'installation et l'usage sont donc, aussi bien au niveau client que serveur, simples et courants, tout en ne nécessitant pas du logiciel privateur.

    Ce que j'ai créé ne s'appuie sur rien de spécifique à un système d'exploitation (y compris pour écrire de potentielles données de sessions et de potentiels journaux d'erreurs ou avertissements) et n'a besoin que de la bibliothèque standard de PHP, déposer le code source à un endroit où un serveur web va chercher des ressources et potentiellement exécuter du code PHP (en version 7) suffit pour installer et faire fonctionner la partie serveur. Cette méthode est simple et ne nécessite que d'avoir des droits d'écriture dans un dossier qu'un serveur web utilise.

    Le paquet Debian

    Il y a de fortes probabilités pour que mon outil soit utilisé sur un système Debian ou un dérivé (comme Ubuntu, Mint, et Trisquel GNU/Linux). La manière propre et usuelle pour installer un élément sur un de ces systèmes est de passer par un ou des paquets Debian (qui sont des archives organisées d'une certaine manière et ont usuellement deb comme extension). Un paquet Debian a des avantages (par rapport à une installation par copier/coller), tels que pouvoir être facilement mis à disposition via un dépôt de paquets, contenir des méta-données (comme la version, un journal des modifications synthétique, et la licence de chaque fichier du paquet source), permettre l'installation automatique des dépendances (avec APT ou un outillage similaire), et il peut être vérifié qu'il suit les bonnes pratiques. Il a donc été décidé de faire un paquet Debian, ou plutôt un moyen automatique et aisé d'en faire un.

    Le plus gros du travail est fait par dh_make, qui est un programme libre qui automatise de nombreuses parties de la construction d'un paquet Debian propre. Hormis le fichier control (qui contient une partie importante des méta-données) et le fichier copyright (qui indique des informations vis-à-vis des auteurs/autrices et des licences), il a essentiellement fallu faire une règle install et une autre uninstall dans le makefile (qui permettent respectivement, par logique élémentaire et convention, d'installer et de désinstaller un projet utilisable) (en utilisant le paramètre facultatif DESTDIR, qui permet par exemple de faire une installation à un emplacement où il n'y a pas besoin de privilèges d'écriture de SuperUser/root) que dh_make utilise automatiquement, comme la règle test (quand elle existe) qui lui permet de tester que les tests passent avant une potentielle construction du paquet.

    La construction est faite avec debuild qui appelle le programme Lintian. Celui-ci fait des tests sur les paquets et signale des erreurs pour les problèmes graves (qui ne sont pas tolérés pour un paquet dans l'archive Debian officiel) ainsi que des avertissements pour les problèmes non significatifs (mais dont l'évaluation pourrait changer à l'avenir) (comme des fichiers sans licence ou l'inclusion de jQuery alors que cette bibliothèque JavaScript est déjà packagée dans libjs-jquery et ne devrait pas être installée plusieurs fois). Toutes les erreurs et avertissements ont été corrigés, mais il y aurait probablement des petites choses à améliorer. La création automatique du paquet en génère donc un de qualité, bien qu'il ne soit pas parfait.

    Possibilités pour améliorer les performances

    • Réécrire le logiciel en langage Go : c'est un langage avec 2 implémentations libres (l'officielle et gccgo), qui peut se compiler en code natif (contrairement à PHP) et est adapté pour le Web (ce dont on peut se douter quand on connait son auteur, à savoir Google)
    • Réécrire les parties nécessitant une puissance de calcul non négligeable en C ou C++ et les appeler en PHP (le C peut aussi être appelé en Go)
    • Actuellement, il y a une classe par cas à gérer (lien, image, formulaire, script, etc.), ce qui permet de décomposer au maximum. Pour les documents HTML, chaque classe fait une requête XPath. Il serait possible d'en faire moins avec une classe qui aurait plus de responsabilités, au détriment de la qualité et maintenabilité du code source.
    • Manipuler le HTML en JavaScript sur le client : cela déchargerait notablement le serveur, mais cela nécessiterait la gestion du JavaScript sur le client et il faudrait arriver à faire les changements d'URL avant que le client web ne les utilise pour obtenir les ressources correspondantes.
    • Mon proxy récupère toutes les ressources demandées, mais il n'a aucun mécanisme de cache, ce qui peut le conduire à demander inutilement une même ressource plusieurs fois. Une solution serait d'implémenter un mécanisme de cache dans mon proxy, cela demanderait du temps mais aurait l'avantage que ce soit intégré et donc installé automatiquement. Une autre solution est de le faire utiliser un proxy web (comme Squid, Polipo, ou Varnish HTTP Cache), ce qui est facile et permet de ne pas recréer la roue, ainsi que d'être optimisé et déjà testé. Cette possibilité d'ajouter un cache n'a d'intérêt que s'il y a plusieurs utilisateurs/utilisatrices, si plusieurs clients web ne partageant pas un cache commun sont utilisés, ou si au moins un des clients web utilisés n'a pas de cache.

    Et après ?

    Il reste des cas non gérés ou mal gérés, comme la "proxification" des URLs dans le CSS, l'attribut pour l'intégrité en HTML, et un problème d'encodage sur de rares sites web. De plus, l'interface graphique est fonctionnelle et simple, mais a une apparence graphique très sobre, ce qui pourrait être changé par exemple avec un style CSS pré-existant comme KNACSS (qui est sous licence WTFPL), Milligram ou Twitter Bootstrap (qui sont sous la licence libre "MIT"). Il y a donc des choses à faire pour améliorer l'existant.

    On peut aussi vouloir aller au-delà. Il pourrait par exemple être intéressant de faire un moyen d'exporter les données pour Apache JMeter et Tsung, qui sont 2 outils libres qui peuvent prendre du XML en entrée et qui sont packagés par la majorité des distributions GNU/Linux. Les flux de syndication (au format Atom et RSS) ne sont pas gérés, or certains navigateurs web les gèrent. De plus, on pourrait imaginer une séparation de l'API web et de l'interface graphique en 2 services différents (mais dont l'un dépend de l'autre), ce qui faciliterait la contribution à une seule des 2 parties et simplifierait la maintenance de chacune.

    Il y a de nombreux tests unitaires, du moins pour PHP (qui représente la vaste majorité du code). Ainsi pour environ 15 000 lignes de codes PHP utilisés dans l'application, il y a environ 10 000 lignes de tests unitaires en PHP (chiffres obtenus respectivement avec wc -l src/include/php/class/* et wc -l tests/php/*, ce qui inclut les commentaires dont les en-têtes pour spécifier la licence de chaque fichier, les lignes vides, etc.). Il y a également d'autres tests automatiques et pas uniquement sur le code PHP. Il y a donc un filet de sécurité si l'on veut contribuer sans casser le fonctionnement et écrire le code en respectant certaines règles (pour qu'il garde une certaine homogénéité et soit donc plus facile à lire que s'il n'en avait pas). Puisque les 2 langages de programmation utilisés sont PHP et JavaScript (on fait ici exception du XSLT qui représente environ 300 lignes de code, ainsi que de HTML et CSS que tout développeur/développeuse web connait), il est facile de trouver une personne compétente pour modifier le code, car ce sont des langages courants et qui ne disparaitront pas avant de nombreuses années.

    Pourquoi ce nom ?

    Le nom originel est CLIF Web Proxy (d'où le logo qui n'a pas été modifié par la suite). C'était trivial et ça reflétait bien le projet, un proxy web pour le logiciel CLIF pour celles et ceux qui auraient directement sauté à cette partie (ou presque). Puisque le logiciel que j'ai produit peut être utilisé comme simple proxy web et qu'il pourrait servir pour d'autres logiciels de test de charge que CLIF, j'ai décidé de lui donner un nom plus général.

    Continuant dans mon imagination prodigieuse, je l'ai nommé RyDroid Web Proxy. Cela permet de rendre hommage au Créateur Suprême. En effet, RyDroid est un pseudonyme qu'il utilise couramment sur Internet. Certains racontent que c'est un mégalomane, tandis que d'autres prétendent qu'il avait bien peu d'imagination (au moins à ce moment là), je vous laisse vous faire votre avis. Après tant d'explications techniques, vous me ou lui (c'est qu'on se perd !) pardonnerez un moment de déconne et ça peut permettre de faire émerger un sourire avant la conclusion (quel sens de la transition !).

    Conclusion

    J'ai réalisé un proxy pour enregistrer une session web et la sauvegarder dans un format pour un outil de test de charge (en l'occurrence CLIF). Il est utilisable en l'état, mais il y a des manques qui peuvent être dérangeants dans certaines situations, et des fonctionnalités additionnelles qui pourraient être plaisantes. 2 moyens simples d'installation sont proposés, ce qui facilite l'utilisation de ma réalisation technique.

    Celle-ci a été publiée via Internet sous une licence libre, ce qui en fait un bien commun. De plus, il ne dépend que de technologies libres, ce qui permet d'avoir un contrôle total sur ce qu'il fait, mais aussi sur son évolution future, à laquelle un ou plusieurs autres contribueront potentiellement. Grâce au copyleft, les personnes distribuant des versions modifiées ont l'obligation légale de mettre leurs apports dans le pot commun, et ainsi créer un cercle vertueux qui ne soit pas basé sur l'exclusivité.

    Bonnes captures Web et vive le logiciel libre !

    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

  • France Culture: que reste-t-il du logiciel libre ? (Journaux LinuxFR)

    Bon jour Nal !

    L'émission Du grain à moudre d'hier, sur France Culture, posait cette question: « Que reste-t-il du logiciel libre ». Des représentants de Framasoft et de Microsoft tentaient de répondre à la question. On peut écouter l'émission en podcast.

    J'écoutais vaguement en faisant la cuisine… J'en ai néanmoins déduit une conclusion:

    • Le modèle économique du logiciel libre, qui consiste à vendre un service plutôt que le logiciel l'a emporté. C'est du moins le modèle économique que le représentant de Microsoft considère dorénavant le plus viable.
    • Le logiciel libre, entendu comme 4 libertés, prospère dans les piles logicielles éloignées de l'utilisateur final, mais peine à s'imposer dans les logiciels plus proches de l'utilisateur final.
    • L'éthique que certains (dont moi) associent au logiciel libre, de maîtrise de son outil de travail ou de ses données perd du terrain. Non seulement parce que le modèle du service (dans les nuages) s'est imposé, mais aussi parce que d'une manière générale, plus l'on s'approche de l'utilisateur final, moins on trouve de logiciel libre.

    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

  • Tableur de calcul pour auto-entrepreneur 2016 (Journaux LinuxFR)

    Je tenais à partager ce petit tableur que j'ai moi même fait avec LibreOffice Calc (compatible avec tous les tableurs). Calculez vos dépenses/recettes/charges/bénéfices et tenez un "cahier des comptes" au propre (ou presque) pour vous lancez en tant qu'auto entrepreneur !

    Télécharger le tableur : auto-entrepreneur-calcule-2016.ods

    C'est simple, regroupez vos factures, additionnez les celons vos dépenses/recettes et saisissez les pour calculer vos charges !

    Si vous bénéficiez de l'ACCRE, ajustez votre Taux dans la formule des cellules RSI Taxe

    Je vais pas vous faire un dessin et vous expliquez comment ça marche, c'est pas bien compliqué ! ;)

    Heux, je tien à dire Merci à LinuxFR d'avoir banni mon compte sans aucunes mentions, aucun mail, ni rien ? C'est génial de voir des gens critiquer sans apporter quelconques solutions, ni contributions, mes projets sont loin d’être parfait, certe, mais au lieux de rester sur votre petit cul a rien faire, aidez moi concrètement ! :P ;)

    Peace ☮

    mario_26

    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

  • 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

  • Lazy FPU state restore (Dépêches LinuxFR)

    Intel est de nouveau confronté à la découverte d'une faille, le
    Lazy FPU State Restore flaw.
    Cette fois, seule la famille des intel core serait concernée.

    Sommaire

    Le FPU

    L'unité de calculs flottants, le FPU, possède une série de registres qui lui permet de définir son état courant.
    Lors du basculement d'une tâche à une autre ( context switch), cet état est alors restauré pour retrouver un contexte correspondant au processus en cours.

    Ces opérations peuvent être coûteuses car les registres sont plus gros que ceux du CPU, c'est pourquoi les FPU fournissent une option pour désactiver toute opération flottante (CR0:TS) ; aussi, dès qu'un calcul flottant est appelé une exception est lancée pour réveiller le FPU avant de lancer l'opération normalement.
    Lorsque cette exception (fpudna, FPU Device Not Available) se produit, un gestionnaire de contexte fpu vérifie quel processus a la main sur le FPU à ce moment-là.
    S'il s'agit d'un autre processus, il procède à la sauvegarde puis restauration des registres, ou s'il s'agit d'un nouveau contexte, la sauvegarde puis nettoyage des registres ; sinon, il ne fait rien : c'est le mode «paresseux» (lazy). À la sortie du processus, il ne faut pas oublier de nettoyer ces tables et de (re)lever tous les drapeaux liés à cette exception.

    En mode eager (zélé, volontaire), la sauvegarde/restauration des registres associés au FPU est effectuée quoiqu'il advienne, au moment du changement de tâche et non durant l'exécution de la tache qui vient de prendre la main.

    Le bâton

    Au fil des années, les processeurs ont multiplié les registres pour prendre en charge les instructions de type SIMD, soit une instruction capable de procéder au même calcul sur un ensemble de paires de données.

    Les registres SSE, AVX et MMX restent associés au FPU et seront donc intégrés au mécanisme de sauvegarde/restauration…
    … et ils peuvent contenir jusqu'à 2Kb de données, rien que sur l'AVX.

    [    0.000000] Linux version 4.14.48-intel-pk-standard (oe-user@oe-host) (icc version 18.0.2 (gcc version 7.3.0 compatibility)) #2 SMP PREEMPT Wed Jun 20 13:21:48 UTC 2018                                                              
    [    0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'                               
    [    0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'                                              
    [    0.000000] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers'                                       
    [    0.000000] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR'                                                    
    [    0.000000] x86/fpu: xstate_offset[3]:  576, xstate_sizes[3]:   64                                                
    [    0.000000] x86/fpu: xstate_offset[4]:  640, xstate_sizes[4]:   64                                                
    [    0.000000] x86/fpu: Enabled xstate features 0x1b, context size is 704 bytes, using 'compacted' format.
    

    Pour se faire battre

    Par le biais désormais connu de l’exécution spéculative puis de l'analyse de cache, un attaquant pourra lire ces registres depuis un autre processus, voire, depuis une machine virtuelle. En effet, en mode lazy la sauvegarde des registres d'une tâche s'effectue au cours de l'exécution d'une autre tâche. La spéculation ignorant le drapeau CR0:TS, tout est alors possible.

    Ces registres peuvent contenir des informations sensibles comme des clefs de chiffrement (AES), par le biais des instructions d'accélération matérielle AES-NI.

    Delivers Fast, Affordable Data Protection and Security. AHeum.

    Colin Percival, ex membre de l'équipe sécurité de FreeBSD, a codé un exploit en quelques heures et note, dans un tweet :

    You need to be able to execute code on the same CPU as the target process in order to steal cryptographic keys this way. You also need to perform a specific sequence of operations before the CPU pipeline completes, so there’s a narrow window for execution

    Vous devez être en mesure d'exécuter le code [de l'exploit] sur le même CPU que celui de la cible pour voler les clefs de cette manière. Vous devrez en outre appliquer une suite précise d'opérations avant que la chaîne de traitement du CPU ne se termine ; de fait, la fenêtre de tir est très étroite.

    Ce qui semble vouloir dire que, pour l'instant, coder le vol de données depuis un script venu du Web n'est pas simple à produire. Le temps nécessaire au vol des données des registres est la clef de l'attaque. Il faut le terminer avant que le séquenceur ne préempte la victime et que les valeurs des registres ne soient modifiées.

    Pour y arriver, les chercheurs ont utilisé plusieurs méthodes:

    • Exception

    Il s'agit de coder la fuite de données à l'ombre d'une exception, sciemment provoquée, tel un page fault par exemple. Mais il s'avère que cette solution est trop lente pour récupérer tout un jeu de registres.

    • Intel TSX

    Cette mécanique n'est disponible que sur les architectures récentes (à partir de Haswell) ce qui limite l'angle d'attaque. Cette technologie comporte un jeu d'instructions appelé RTM (Restricted Transactional Memory) qui permet d'annuler un bloc d'exécution en cas d'interruption ; il suffit d'y encadrer le code malicieux, qui va innocemment faire appel au FPU, pour lever l'exception fpudna… Ce serait presque « étudié pour ».

    • Retpoline

    Il s'agit au départ d'une contre-mesure pour spectre.
    Elle vise à fourvoyer sciemment le CPU sur l'adresse de retour d'un RET en plaçant une fausse boucle et donc le forcer à exécuter de manière spéculative un code innocent. Le code malicieux sera donc placé à cet endroit.

    Les correctifs

    Le mode lazy semble moins pertinent aujourd'hui. Les gains en performance sont faibles sous les architectures récentes et surtout selon les usages actuels ; voire, le FPU étant beaucoup plus utilisé dans nos logiciels, son usage serait contre-productif.
    En effet, les compilateurs choisissent d'appeler les instructions SIMD (i.e. -sse) pour optimiser le code des logiciels. De fait, ceux-ci auront de toute façon sauvegardé et restauré les registres du FPU à chaque changement de contexte. La gestion de l'exception sera inutile et va juste alourdir le processus.
    En outre, l'empreinte d'une sauvegarde/restauration serait moindre que celle de la gestion des drapeaux, des registres et de leurs états suite à l'interruption, le transfert de registres FPU en mémoire étant plus rapide car optimisé.

    Il est donc préconisé d'éviter le mode lazy au profit du mode eager.

    • Linux propose le mode eager plutôt que le mode lazy depuis la version 3.7 et l'active par défaut depuis la version 4.9.

      • Ajoutez eagerfpu=on sur la ligne de démarrage pour les versions antérieures à la 4.9.
    • FreeBSD a poussé un patch pour la Release 11.2. C'est un FreeBSD 11.1 qui a servi de cobaye ;

    • DragonFly BSD a poussé un patch dans la version 5.2.2 ;

    • Microsoft poussera un patch en juillet ;

    • OpenBSD a poussé un patch le 14 juin pour la version 6.3 ;

    • NetBSD a poussé un patch le 16 Juin sur MAIN .

    Conclusion

    Ils ne sont pas à la fête cette année, chez Intel. Le point positif est que la correction de cette faille devrait conduire à une amélioration des performances, voire de la consommation d'énergie.

    Theo de Raadt avait prévenu 11 ans auparavant que l'architecture Intel Core2 promettait ce genre de faille :

    These processors are buggy as hell, and some of these bugs don't just
    cause development/debugging problems, but will ASSUREDLY be
    exploitable from userland code.

    Ces processeurs sont bugués comme jamais et nombre de ces bugs ne provoquent pas seulement des soucis de développement et d'analyse, mais ils vont assurément être exploitables depuis l'espace utilisateur.

    Pour la petite histoire, l'embargo s'est terminé le 6 Juin.
    Colin Percival, qui assistait à une conférence de Théo de Raadt lors de la BSDCan 2018, a codé un exploit dans la foulée, qu'il n'a pas encore rendu public. Mais il a convaincu Intel de lever l'embargo au plus vite.
    Il est notable qu'aucun des deux n'avait été mis dans la confidence ; OpenBSD signale même qu'ils en ont fait la demande ( des rumeurs circulaient autour d'une énième version de spectre) mais sans obtenir de réponse.

    Invitation to Embargo? No.
    We asked.

    No reply.

    Commentaires : voir le flux atom ouvrir dans le navigateur

  • Faille Lazy FPU state restore (Dépêches LinuxFR)

    Intel est de nouveau confronté à la découverte d’une faille, le Lazy FPU State Restore flaw.
    Cette fois, seule la famille des Intel Core serait concernée.

    Sommaire

    Le FPU

    Le FPU, c’est le bordel, par Ingo Molnar

    L’unité de calcul en virgule flottante, le FPU, possède une série de registres qui lui permet de « définir » son état courant. Lors du basculement d’une tâche à une autre (context switching), cet état est alors restauré pour retrouver un contexte correspondant au processus en cours. Ces opérations peuvent être coûteuses car les registres du FPU sont plus gros que les autres, c’est pourquoi les FPU fournissent une option pour désactiver toute opération en virgule flottante (CR0:TS). Aussi, dès qu’un calcul en virgule flottante est appelé, une exception est lancée pour « réveiller » le FPU avant de lancer l’opération normalement.
    Lorsque cette exception (fpudna, FPU Device Not Available) se produit, un « gestionnaire de contexte FPU » vérifie quel processus a la main sur le FPU à ce moment‐là.
    S’il s’agit d’un autre processus, il procède à la sauvegarde puis la restauration des registres, ou s’il s’agit d’un nouveau contexte, la sauvegarde puis le nettoyage des registres ; sinon, il ne fait rien : c’est le mode « paresseux » (lazy). À la sortie du processus, il ne faut pas oublier de « nettoyer » ces tables et de (re)lever tous les drapeaux liés à cette exception.

    En mode eager (zélé, volontaire), la sauvegarde et restauration des registres associés au FPU est effectuée quoiqu’il advienne, au moment du changement de tâche et non durant l’exécution de la tâche qui vient de prendre la main.

    Le bâton

    Au fil des années, les processeurs ont multiplié les registres pour prendre en charge les instructions de type SIMD, soit une instruction capable de procéder au même calcul sur un ensemble de paires de données.

    Les registres SSE, AVX et MMX restent associés au FPU et seront donc intégrés au mécanisme de sauvegarde et restauration… et ils peuvent contenir jusqu’à 2 048 bits de données, rien que sur l’AVX.

    [    0.000000] Linux version 4.14.48-intel-pk-standard (oe-user@oe-host) (icc version 18.0.2 (gcc version 7.3.0 compatibility)) #2 SMP PREEMPT Wed Jun 20 13:21:48 UTC 2018                                                              
    [    0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'                               
    [    0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'                                              
    [    0.000000] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers'                                       
    [    0.000000] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR'                                                    
    [    0.000000] x86/fpu: xstate_offset[3]:  576, xstate_sizes[3]:   64                                                
    [    0.000000] x86/fpu: xstate_offset[4]:  640, xstate_sizes[4]:   64                                                
    [    0.000000] x86/fpu: Enabled xstate features 0x1b, context size is 704 bytes, using 'compacted' format.
    

    Pour se faire battre

    Par le biais désormais connu de l’exécution spéculative puis de l’analyse de cache, un attaquant pourra lire ces registres depuis un autre processus, voire depuis une machine virtuelle. En effet, en mode lazy la sauvegarde des registres d’une tâche s’effectue au cours de l’exécution d’une autre tâche. La spéculation ignorant le drapeau CR0:TS, tout est alors possible.

    Ces registres peuvent contenir des informations sensibles comme des clefs de chiffrement (AES), par le biais des instructions d’accélération matérielle AES-NI.

    Delivers Fast, Affordable Data Protection and Security. AHeum.

    Colin Percival, ex‐membre de l’équipe sécurité de FreeBSD, a codé un exploit en quelques heures et note, dans un tweet :

    « You need to be able to execute code on the same CPU as the target process in order to steal cryptographic keys this way. You also need to perform a specific sequence of operations before the CPU pipeline completes, so there’s a narrow window for execution. »

    « Vous devez être en mesure d’exécuter le code de [l’exploit] sur le même processeur que celui de la cible pour voler les clefs de cette manière. Vous devrez en outre appliquer une suite précise d’opérations avant que la chaîne de traitement du processeur ne se termine ; de fait, la fenêtre de tir est très étroite. »

    Ce qui semble vouloir dire que, pour l’instant, coder le vol de données depuis un script venu du Web n’est pas simple à réaliser. Le temps nécessaire au vol des données des registres est la clef de l’attaque. Il faut le terminer avant que le séquenceur ne préempte la victime et que les valeurs des registres ne soient modifiées.

    Pour y arriver, les chercheurs ont utilisé plusieurs méthodes :

    Exception

    Il s’agit de coder la fuite de données à l’ombre d’une exception, sciemment provoquée, tel un page fault, par exemple. Mais il s’avère que cette solution est trop lente pour récupérer tout un jeu de registres.

    Intel TSX

    Cette mécanique n’est disponible que sur les architectures récentes (à partir de Haswell), ce qui limite l’angle d’attaque. Cette technologie comporte un jeu d’instructions appelé RTM (Restricted Transactional Memory) qui permet d’annuler un bloc d’exécution en cas d’interruption ; il suffit d’y encadrer le code malicieux, qui va innocemment faire appel au FPU, pour lever l’exception fpudna… Ce serait presque « étudié pour ».

    Retpoline

    Il s’agit au départ d’une contre‐mesure pour Spectre. Elle vise à fourvoyer sciemment le processeur sur l’adresse de retour d’un RET en plaçant une « fausse » boucle et donc le forcer à exécuter de manière spéculative un code innocent. Le code malicieux sera donc placé à cet endroit.

    Les correctifs

    Le mode lazy semble moins pertinent aujourd’hui. Les gains en performance sont faibles avec les architectures récentes et, surtout, selon les usages actuels. Le FPU étant même beaucoup plus utilisé dans nos logiciels, son usage serait contre‐productif.
    En effet, les compilateurs choisissent d’appeler les instructions SIMD (i.e. -sse) pour optimiser le code des logiciels. De fait, ceux‐ci auront de toute façon sauvegardé et restauré les registres du FPU à chaque changement de contexte. La gestion de l’exception sera inutile et va juste alourdir le processus. En outre, l’empreinte d’une sauvegarde et restauration serait moindre que celle de la gestion des drapeaux, des registres et de leurs états suite à l’interruption, le transfert de registres FPU en mémoire étant plus rapide car optimisé.

    Il est donc préconisé d’éviter le mode lazy au profit du mode eager.

    • Linux propose le mode eager plutôt que le mode lazy depuis la version 3.7 et l’active par défaut depuis la version 4.9 ;
    • ajoutez eagerfpu=on sur la ligne de démarrage pour les versions antérieures à la 4.9 ;
    • FreeBSD a poussé un correctif pour la Release 11.2 ; c’est un FreeBSD 11.1 qui a servi de cobaye ;
    • DragonFly BSD a poussé un correctif dans la version 5.2.2 ;
    • Microsoft poussera un correctif en juillet ;
    • OpenBSD a poussé un correctif le 14 juin pour la version 6.3 ;
    • NetBSD a poussé un correctif le 16 juin sur MAIN ;
    • Illumos a poussé un correctif le 19 juin.

    Conclusion

    Ils ne sont pas à la fête cette année, chez Intel. Le point positif est que la correction de cette faille devrait conduire à une amélioration des performances, voire de la consommation d’énergie.

    Theo de Raadt avait prévenu 11 ans auparavant que l’architecture Intel Core 2 promettait ce genre de faille :

    « These processors are buggy as hell, and some of these bugs don’t just cause development/debugging problems, but will ASSUREDLY be exploitable from userland code. »

    « Ces processeurs sont bogués comme jamais et nombre de ces bogues ne provoquent pas seulement des soucis de développement et d’analyse, mais ils vont assurément être exploitables depuis l’espace utilisateur. »

    Pour la petite histoire, l’embargo s’est terminé le 6 juin. Colin Percival, qui assistait à une conférence de Théo de Raadt lors de la BSDCan 2018, a codé un exploit dans la foulée, qu’il n’a pas encore rendu public. Mais il a convaincu Intel de lever l’embargo au plus vite.
    Il est notable qu’aucun des deux n’avait été mis dans la confidence ; OpenBSD signale même qu’ils en ont fait la demande (des rumeurs circulaient autour d’une énième version de Spectre), mais sans obtenir de réponse.

    Invitation to Embargo? No.
    We asked.
    No reply.

    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

  • 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

  • Réseau domestique : mes choix (Journaux LinuxFR)

    Sommaire

    En lisant le journal de yekcim (avec son beau schéma de réseau domestique), je me suis dis que mon schéma de réseau n'avait pas été mis-à-jour depuis longtemps. Je l'ai donc re-dessiné et (fier comme un paon) j'ai décidé de le vous le montrer.

    C'est l'occasion de partager les solutions que j'ai choisi pour résoudre les problématiques d'un réseau domestique (ce qui est aussi le sujet du journal sus-cité). Je vous encourage aussi à faire de même. Il est toujours intéressant de confronter son opinion et ses choix avec ses pairs !

    Sans plus attendre, voici déjà mon bô dessin :

    LAN

    TL;DR

    La dessous, y'a un gros pavé. Si vous ne voulez pas tout lire, voici un résumé :

    • fonctions "techniques" regroupées et ondulées
    • données sur un NAS qui gère aussi le réseau
    • NFS pour l'accès aux données de partout
    • XBMC (xbox/raspbmc) et UPnPlay (android) pour les fonctions client media
    • Debian partout (ou presque)

    Background

    Puisque c'est mon journal et mon réseau, commençons sans hésiter par un 3615 MaVie.
    Quand j'ai rénové ma maison, j'ai fait mon électricité. Tant qu'a passer des fils, j'en ai profité pour câbler en basse tension (ie: câble Ethernet) toutes les pièces. je me retrouve donc avec 32 prises RJ45 toutes ramenées au tableau électrique (dans la GTL située au 1er étage) Il me suffit de les brasser vers le téléphone ou le switch (ou autre chose genre téléinfo) pour choisir leur utilisation.

    Sur le schéma on retrouve donc des lignes verticales représentant le réseau de chaque étage. Les taches colorées figurent les pièces. C'est une vue logique, pas physique. Je me doute bien que savoir que guiautec est relié à la prise murale E1CT05 elle même reliée à la prise A06 de la baie de brassage et au port ge3 du switch ne vous intéresse pas :)

    Le nommage des machines suit 2 règles : des noms d’îles de l'archipel des Glenan pour les généralistes et la fonction (ou la marque) pour les équipements spécialisés.
    Côté OS, c'est assez homogène avec du Debian (testing) partout :). On notera quand même un Windows 8 pour l'adolescente (uniquement pour Les Sims 4) et une machine virtuelle Windows 7 (non représentée) sur mon PC pour des outils de développement WIN only (du Python et gcc, franchement, ils auraient pu faire une version Linux !). Et bien sur, les équipements mobiles en Android.

    GTL : fonctions techniques

    Dans ce petit placard, sont regroupées toutes les fonctions "techniques".

    Le point névralgique de mon réseau (outre le switch) est le NAS qui assure toutes les fonctions de management du réseau. C'est un Synology DS213j. Il a remplacé un NAS homemade à base de mini-ITX via epia qui a rendu l’âme il y a quelques mois. Le basculement vers une appliance clef en main a été dicté par une volonté de simplifier l'administration. Je suis très content de ce choix ! J'ai très peu perdu en souplesse et fonctions, mais beaucoup gagné en simplicité de gestion.

    Il assure les fonctions réseau (DHCP, DNS, NTP …) car je fais moyennement confiance à la Livebox pour cela. De plus cela me donne beaucoup plus de maîtrise de ce qui se passe.
    Évidement, il me permet aussi d'héberger toutes mes données (musique, vidéos, photos et autres documents) et de les partager avec les autres machines du réseau.
    Il m'offre des fonctions annexes tel git ou un MariaDB accessibles de partout.
    Et enfin il gère toute la partie sauvegarde que nous verrons plus loin.

    Le switch est un Netgear GS724T gigabit. Il est administrable via une page web et offre une interface snmp. Au moment de l'achat c'était le gigabit (administrable) avec suffisamment de ports le moins cher. À noter (voir ci-dessous) qu'il permet aussi de gérer des VLANs.

    Côté domotique, je n'ai pas grand chose. Un RaspberryPi (sous Debian) gère cela :

    • La téléinfo EDF qui est stockée dans la BdD du NAS. Les graphiques sont accessibles via un serveur lighttpd hébergé directement sur le Pi.
    • Le Fil pilote (un seul radiateur pour le moment) est géré via une interface USB simple. Je ne l'utilise que pour allumer le sèche serviette de la salle de bain (parentale) pour les douches du matin. La aussi une interface web permet de le programmer.

    Enfin tout ce petit monde est branché (230V) sur un onduleur MGE Ellipse 1000. J'avais choisit MGE pour son soutien au libre (via NUT). Il est managé en USB par le NAS qui peut ainsi s'éteindre avant la coupure définitive. Le Pi accède aussi à ces informations via le réseau. C'est très appréciable car j'ai déjà cramé la carte SD d'un Pi à cause de micro coupures à répétition. Acheté en décembre 2006 j'ai du remplacer ses batteries le mois dernier (par contre il a coupé d'un coup sans prévenir :( ).

    1er étage : les machines de tout le monde

    Dans le "secrétariat" on trouve la machine en libre service (huic) qui sert pour les papiers et les comptes (et regarder des vidéos de minecraft sur youtube). C'est ma machine génération N-1.

    Pour imprimer et scanner j'ai choisit une imprimante réseau (Xerox phaser 6110MFP achetée en décembre 2008). La aussi l'administration s'en trouve simplifiée et tout le monde y a directement accès. Pour scanner, j’utilise le script perl de Jon Chambers démarré à la demande sur le NAS. Les documents sont alors accessibles en NFS.

    Dans mon bureau se trouve ma machine principale (guiautec) qui reste la plus puissante de la maison (elle date de cette année). Ma machine de génération N-2 (penfret) est sur mon établi électronique. Elle me sert principalement à afficher les schémas ou les datasheets quand je soude. Malheureusement sa carte GPIB ISA a cramé récemment et la machine elle-même donne de sérieux signes de fatigue. Je ne pense pas la remplacer, mon portable de récup fera bien l'affaire (sauf pour le GPIB :( )

    Pour les enfants, notre adolescente a (ENFIN! selon elle) son propre PC (bananec) et la petite utilise le PC en libre service. Je n'ai pas mis de proxy, de filtre parental ou autre. Nous croyons aux vertus de l'éducation (pour le moment …). De plus, elles connaissent les compétences de leur père ce qui sert d'arme de dissuasion ;)

    2ème : la musique

    Pour la musique, j'utilise une petite tablette chinoise à 2 balles (et écran résistif de merde) qui a le mérite de disposer d'un adaptateur Ethernet. Elle accède aux fichiers via le serveur DLNA du NAS et l'application UPnPlay. On est loin d'une installation de haute fidélité, mais au vu de mes oreilles moisies, c'est suffisant.

    C'est le seul équipement qui fait du DLNA. Ce protocole ne m'a jamais emballé, mais sur cet Android c'est le moyen le plus facile. Si la tablette était récente (et acceptée par Google) j'utiliserai sans doute les applications de Synology qui fonctionnent très bien sur mon téléphone.

    3ème : la vidéo

    Ici se trouve la TV et son boîtier Livebox associé. Soyons honnête il ne sert presque pas puisque nous consommons surtout des films.

    Depuis des années je suis un fervent utilisateur de XBMC, d'abord sur Xbox (sa principale utilisation depuis son achat d'occasion) puis sur RaspberryPi (raspbmc) suite à l’avènement des vidéos en HD.
    L'accès au NAS se faisait en Samba sur la xbox et en NFS sur le Pi.

    Le Pi est commandé via un clavier ou l'appli officielle sous Android. Je compte y ajouter une télécommande infrarouge quand j'aurais fini le projet associé RPiSU

    Sauvegarde

    J'essaye d'avoir une politique correcte de sauvegarde.

    • Chaque PC sauvegarde ses données (en gros /etc et /home) en Rsync (avec anacron et un petit script maison) dans un répertoire du NAS.
    • Le NAS est en RAID histoire de ne pas paumer ses données en cas de panne de disque (oui je sais ce n'est pas de la sauvegarde)
    • Toutes les nuits les données (importantes) du NAS et le répertoire de sauvegarde des PCs est copié (avec historique) sur un disque externe USB. Ce sont les outils de Synology qui permettent l'historique.

    Il me manque la sauvegarde off-site que je suis en train (depuis très longtemps …) d'étudier : cloud, synchro avec un NAS distant …

    VLAN : restreindre les enfants

    Une fonction que je n'ai plus d'implémentée dans le réseau actuel mais qui était en place quand les enfants étaient trop petits pour avoir leur propre accès Internet.

    Un WRT54G (sous OpenWRT) offrait un 2ème accès Wifi avec un vlan particulier. Certains ports du Switch étaient aussi dans ce vlan. Les enfants n'avaient accès qu'à ce Wifi ou ces ports particuliers. Ainsi ils pouvaient avoir accès aux données du NAS (films, photos, musique) mais n'avaient pas d'accès à internet (depuis leur chambre). Cela permet de les avoir en visu quand il y accèdent et de leur prodiguer les conseils et aide nécessaires.

    Évolutions éventuelles

    Le réseau domestique tel qu'il est actuellement nous convient et ne devrait pas beaucoup évoluer dans les temps à venir :

    • J'envisage de mettre en place une sauvegarde off-site.
    • J'ai aussi l'intention d'éteindre le Wifi de la Livebox (étage des chambres) pour installer mon WRT54G au 2ème étage (la ou les téléphones/tablettes) sont le plus utilisées.
    • je cherche aussi (doucement) un moyen de grapher toutes ces fonctions. Avant j’utilisais Munin mais sa lourdeur ne m'incite pas à la faire tourner sur mon NAS ou mon Pi

    Voila, bravo à ceux qui sont arrivés jusque la.
    Et maintenant c'est à votre tour, quels sont vos choix et solutions pour votre réseau domestique ?

    Lire les commentaires

  • 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

  • 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

  • Neatmail: un client mail minimaliste (Journaux LinuxFR)

    Sommaire

    J’utilise depuis quelque temps un tout petit client mail, qui ne fait vraiment que le minimum, mais a une interface si particulière, qu’il me semble intéressant de vous le présenter. Il s’agit de Neatmail écrit par Ali Gholami Rudi.

    Ali Gholami Rudi

    Je connais Ali Gholami Rudi pour une implémentation de Troff à la fois pertinente en termes de fonctionnalités et dont le code source est très propre. Il a aussi écrit un compilateur (neatcc), une libc (neatlibc), et une implémentation de vi. C’est un développeur qui, plutôt qu’une éthique, semble défendre une certaine esthétique du logiciel, que je qualifierai de minimaliste: code source compréhensible par une personne seule, logiciel qui fait peu de choses, mais le fait bien, etc.

    Neatmail le client mail qu'il s'est programmé, et celui‐ci met en scène toute l’esthétique de son auteur.

    Ce que Neatmail ne fait pas

    Neatmail ne fait que gérer un fichier mbox (une concaténation de mails). Ainsi, il ne sait ni rapatrier, ni envoyer les mails, il ne sait ni extraire, ni ajouter de pièce jointes, etc.

    Mais en vérité, il n’a pas besoin de faire tout cela, car d’autres logiciels le font. Ali Gholami Rudi propose ainsi un pop3 pour rapatrier les mails depuis un serveur pop3, et smtp pour envoyer ses mails à un serveur smtp. Et il existe dans certaines distributions un ripmime pour extraire les pièces jointes d’un fichier mime.

    Ce que Neatmail fait

    Neatmail se contente donc d’effectuer des actions sur un fichier mbox. Les actions de bases sont:

    mk Génère une liste des mails contenus dans la mbox.
    ns Génère une liste des nouveaux mails présents dans la mbox.
    pg Affiche un des mails contenu dans la mbox.

    On peut donc l’utiliser ainsi:

    # Obtient les mails
    pop3
    # liste les mails, triés par fil de discussion
    neatmail mk ‐r ‐st ‐0 18from:48~subject: mbox
    # affiche le 3e mail
    neatmail pg mbox 3
    # prépare une réponse
    neatmail pg ‐r mbox 3 > draft.eml
    vi draft.eml
    # envoie la réponse
    tail ‐n+2 draft.eml | smtp
    # garde une copie de la réponse
    cat draft.eml >> sent
    rm draft.eml

    Mais en outre, neatmail peut interpréter les commandes ex contenues dans la liste des mails. Autrement dit, l’utilisateur est invité à ajouter des commandes à cette liste de mails, et donner le tout à neatmail qui se chargera de l’exécution:

    neatmail mk ‐r ‐0 18from:48~subject > list.nm
    vi list.nm
    neatmail ex < list.nm

    Le commande ex de neatmail

    La commande ex de neatmail prend en entrée une liste de commandes, et les exécute sur un fichier mbox. Elle ignore toutes les lignes hormis celles commençant par deux points (commande ex) ou une lettre majuscule (un mail dans la liste). Les lignes commençant par une lettre majuscule de la forme "R100..", modifient le statut du message dont le nombre suit la lettre (ici, 100). Une telle ligne définit aussi le message actuel, celui sur lequel les commandes sont exécutées. Les commandes ex sont les suivantes:

    rm supprime le message courant.
    cp copie le message courant dans une mbox donnée.
    mv déplace le message courant dans une mbox donnée.
    hd modifie l’entête donnée du message courant.
    ft passe le message courant à une commande donnée.
    w écrit les modifications dans la mbox.
    tj joint les fils de discussion en modifiant l’entête "Reply‐To".
    ch coupe le message à l’offset indiqué.

    Par défaut, ces commandes agissent sur le message courant, mais il est aussi possible d’utiliser des adresses du type 2,5rm pour effacer les messages 2 à 5. Il est aussi possible d’utiliser des expressions régulières du type /regex/rm, où regex est recherché dans le sujet des messages. D’autres champs peuvent être spécifiés en utilisant l’expression ^field:value.

    Un script shell comme interface

    Vous allez certainement penser que l’interface est un peu rude… À vrai dire, Ali Gholami Rudi n’utilise pas neatmail directement: un script shell (m) lui sert d’interface. Et c’est là que le logiciel brille: pour peu que l’on ait un peu l’habitude du shell, on peut se créer une interface sur mesure. On peut par exemple imiter l’interface de mh (un autre client mail non interactif un peu oublié). On pourrait créer une interface interactive. Bref, on peut faire ce qu’on veut.

    J’utilise par exemple l’interface suivante:

    m box inbox # liste les messages contenus dans la mbox inbox.
    m vi 3 # affiche le message 3
    m next # affiche le message 4
    m repl # ouvre mon éditeur sur une réponse préformatée au message 4
    m add f.pdf # joint f.pdf à ma réponse
    m send # envoie ma réponse.
    m R # marque le message 4 comme lu.
    m com # enregistre les changements dans la mbox (ici, change l’entête du message 4)

    Conclusion

    Au jour le jour, je suis plutôt satisfait de l’ensemble. Le fait de travailler sur les mails en local est plutôt agréable: c’est fluide, offre une grande liberté d’organisation, s’associe bien à un système de sauvegarde ou de gestion de version, etc. Le fait que le client ne soit pas interactif apporte un certain confort d’usage: le shell est sous la main si besoin, je retrouve ma session de travail dans l’état où je l’ai laissée d’un jour à l’autre, il est facile d’implémenter des solutions pour revenir en arrière (cp…). Le fait de coupler le tout avec le shell offre une grande liberté dans la création de l’interface utilisateur.

    Commentaires : voir le flux atom ouvrir dans le navigateur

  • QElectroTech 0.3 (Dépêches LinuxFR)

    Trois ans après la dernière version stable de QElectroTech (QET), la version 0.3 est maintenant disponible en téléchargement.

    Pour rappel, QElectrotech est un logiciel libre multi‐plate‐forme, permettant de réaliser des schémas électriques pour représenter des circuits électriques. Sous licence GNU GPL, développé en C++ avec la bibliothèque Qt 4.

    NdM : apparemment, QET est utilisé en France en bac pro filière Électrotechnique.

    Nouveautés

    Tout d’abord, la collection d’éléments se voit grandir d’un bond de géant avec environ 1 560 nouveaux éléments. Avec l’arrivée d’autant d’éléments, le panel d’éléments était devenu lent. Un cache sqlite a été implanté pour répondre à cette problématique.

    Dans la collection d’éléments, nous avons maintenant des symboles pour les métiers : pneumatique, hydraulique, électronique, processus, solaire, froid, etc.
    Un gros classement sur la structure de la collection a été réalisé. Ça devrait être plus clair pour tout le monde.

    Captures d’écran de travaux professionnels réalisés avec QET.
    http://download.tuxfamily.org/qet/screens/index.html

    Exemple de schéma avec un arduino :
    qet-exemple
    Exemples trouvés sur le www :
    qet-exemple
    qet-exemple1
    qet-exemple2

    Nous avons ajouté :

    • l’importation d’images dans les folios, qui nous a été grandement demandée ;
    • QET permet aujourd’hui d’importer des images dans vos schémas, de les redimensionner et d’enregistrer les images ainsi que leurs positions dans le fichier .qet ;
    • la rotation d’images ;
    • la possibilité d’« annuler/recommencer » (Ctrl + Z, Ctrl + Maj + Z) fonctionne comme pour les symboles.

    La numérotation incrémentale des conducteurs et l’ajout d’un dialogue pour pivoter automatiquement le texte si son conducteur est vertical ou horizontal. Les paramètres sont enregistrés dans votre fichier qelectrotech.conf.

    qet-num
    qet-num2

    Un gros travail a été réalisé sur les zones de texte avec la possibilité de les déplacer ou de les tourner. Il est aussi possible de changer la couleur d’un conducteur et de le mettre en pointillé.

    Un éditeur de texte enrichi en HTML pour les champs texte dans les schémas. Il permet de faire des tableaux avec un peu de HTML, de choisir la taille, la couleur du texte, etc.

    qet-text
    qet-text2

    Dans l’éditeur de symbole, un travail important a été réalisé pour remplacer la zone de définition du symbole manuel (hotspot) ; il est maintenant automatique, et vous n’avez plus à vous en soucier. Des couleurs primaires ont été ajoutées pour les formes de dessin. De plus, un menu contextuel (via clic droit) a été ajouté afin de rendre le travail sur les symboles plus rapide et beaucoup plus ergonomique.

    qet-context

    Il est dorénavant possible de créer ou de personnaliser son propre cartouche. Des modèles sont inclus dans QET.

    qet-cartouche

    QET est maintenant disponible en français, anglais, polonais, espagnol, portugais, arabe, tchèque, italien, grec, catalan, roumain, croate, russe et allemand. Suite à la traduction en arabe du logiciel, un travail sur l’écriture de droite à gauche (Rigth To Left) a été réalisé.

    qet-en-arabe

    Les traductions allemande et russe ne sont pas complètes, mais il a été décidé de les fournir tout de même. C’est l’occasion de remercier Alfredo, Yuriy, José Carlos, Pavel, Paweł, Youssef, Gabi, Markus, Jonas, Noah, Alessandro, Silvio, Eduard, Mohamed, Antun, Nikos et Yannis pour leur travail de traduction.

    Vous pouvez télécharger QElectroTech 0.3 depuis notre page de téléchargement :
    http://qelectrotech.org/download.html.

    Paquetages

    Cette version de QET est disponible pour :

    Version 0.4

    Pour la future version 0.4, il est prévu de :

    • gérer les références croisées ;
    • créer une nomenclature ;
    • numéroter les borniers.

    Avis de recherche

    Comme beaucoup de projets du monde libre, QElectroTech recherche des gens motivés (et surtout disponibles) pour rejoindre et renouveler l’équipe existante.

    Le projet est plus particulièrement à la recherche de contributeurs pour les activités suivantes :

    • d’un traducteur de langue maternelle anglaise ayant des connaissances en électrotechnique ;
    • des traducteurs pour continuer l’internationalisation du programme ;
    • d’une personne capable d’écrire une documentation soignée et pédagogique ;
    • d’un empaqueteur pour Mac OS X ainsi que des empaqueteurs pour répandre QET facilement sur les autres distributions GNU/Linux, et pour nous faire des retours sur l’intégration ;
    • des contributeurs pour la collection d’éléments ;
    • des testeurs ayant une réelle procédure de test ;
    • des développeurs C++/Qt pour l’application elle‐même, bien entendu.

    Lire les commentaires

  • 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

  • Mise à jour des pages de manuel pour MeeGo 1.1 (Linux Certif)

    Suite à la mise à jour pour Ubuntu, j'ai découvert un bug dans l'algorithme qui crée les liens entre les pages de manuel.

    Je viens de corriger ça et j'en ai profité pour importer de nouvelles pages de manuel.

    Cette fois, les pages viennent de la distribution MeeGo. La version 1.1 de Meego vient de sortir, c'est donc cette version qui a été importé.

    Assez peu de nouvelles pages ont été importé. Parmi celles-ci, quelques pages inédite de quelques nouveaux outils:

    • bugle
    • gldb-gui
    • Chrome (navigateur par défaut de MeeGo pour Netbook, curieusement cette page de manuel est absente des autres distributions)
    • yumdb
    • etc
  • Pourquoi un PC ralentit-il ? (Journaux LinuxFR)

    Durant toutes ces années, j'ai nourri l'idée que si un PC ralentissait, c'était parce que Windows installait plein de trucs infâmes.

    Pourtant, force est de constater à présent que mes PCs Linux deviennent de plus en plus lents et nécessitent un reformatage annuel, quelque chose que je pensais réservé au Windowsiens.

    Pire : malgré reformatage, les PCs restent beaucoup plus lents qu'avant et je ne l'explique pas vraiment.

    Alors, selon vous, qui est responsable de la lenteur ?

    1. Usure mécanique (notamment pour les HDD qui tournent moins bien et les ventilations qui s'encrassent)

    2. Structure du disque dur qui se corrompt (bad sector) et également, au fil des années sans reformatage, un fragmentage important ? (pour l'anecdote, j'ai un SSD qui ne supporte pas TRIM et, au bout de 3 ans, c'est presqu'inutilisable).

    3. Encombrement logiciel (fichiers de conf et formats de cache qui se transmettent par delà les upgrade et génèrent des bugs)

    4. Évolution du logiciel (les logiciels ne sont plus testés avec d'anciens matériels et buttent sur des petites incompatibilités)

    5. Évolution de notre perception (cela a toujours été lent mais on s'habitue à plus rapide)

    6. Un mix de tout ça ?

    Enfin, bref, tout ça parce que je jette l'éponge sur un de mes desktops qui est passé depuis 7 ans par toutes les versions d'Ubuntu et qui, à présent, se vautre sans raison (le menu Unity ne trouve pas la moitié des applications genre le terminal, Chromium crashe lorsqu'il y a plus de 2 tabs ouvertes, Firefox ne détecte aucun plugin et refuse de les installer). Ce n'est pas venu d'un coup mais ça a vraiment été progressif au cours des 3 dernières années, malgré des ré-installations et un check du disque dur. Mais je constate le même genre de soucis sur d'autres ordinateurs de la même génération.

    Donc je cherche un mini PC de bureau qui soit le plus silencieux, le moins cher possible, avec minimum 4Go de RAM et un connecteur VGA (ou alors, un bon connecteur HDMI -> VGA mais toutes les critiques sur Amazon pour ce genre de produit sont affolantes).

    Merci :-)

    Lire les commentaires

  • 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

  • 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

  • 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

  • PyConFR 2018, du 4 au 7 octobre à Lille : appel à contributions (Dépêches LinuxFR)

    PyConFR18

    La PyConFR, c’est le rassemblement annuel francophone de passionnés et curieux du langage Python. Cette année, on invite la communauté à se retrouver à Lille du 4 au 7 octobre.

    Pour ceux qui ne connaissent pas la formule, les deux premiers jours (jeudi et vendredi) sont dédiés à des sprints (hackathons), et le week‐end sera rempli de conférences et d’ateliers découverte.

    Contribuez à cette édition et aidez‐nous à la rendre mémorable en proposant du contenu : conférences, ateliers, sprints !

    Quelques idées de sujets : enseignement du langage, montée en charge (scaling), sécurité, science des données, apprentissage automatique (machine learning), retour d’expérience, empaquetage, présentation d’une bibliothèque, Internet des objets (IoT), asynchrone, communauté, diversité, pyre-check, 2to3, PyPy, Python vs Go, intégration et livraison continues (CI/CD), stockage de données, agents conversationnels (chatbots), Python magic, Ansible vs SaltStack et tellement d’autres…

    Commentaires : voir le flux atom ouvrir dans le navigateur

  • Nix pour les développeurs (Dépêches LinuxFR)

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

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

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

    Sommaire

    Introduction

    Exemple 1 : créer un environnement de développement de test

    Scénario

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

    # myscript.py
    import numpy
    x = numpy.ndarray(42, int)
    x[0::2] = 13
    x[1::2] = 37
    print(x)

    Avec les outils classiques (Python, virtualenv, pip)

    virtualenv -p /usr/bin/python3 --no-site-packages ~/myvenv
    source ~/myvenv/bin/activate
    pip install numpy
    python myscript.py
    deactivate
    rm -rf ~/myvenv

    Avec Nix

    nix-shell --pure -p python35Packages.numpy --run "python myscript.py"

    Exemple 2 : reproduire un environnement de développement

    Scénario

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

    Avec les outils classiques (par exemple sous Arch Linux)

    sudo pacman -S gcc cmake boost
    mkdir build
    cd build
    cmake ..
    make

    Avec Nix

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

    nix-build
    

    Exemple 3 : empaqueter un projet

    Scénario

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

    Avec les outils classiques (par exemple sous Arch Linux)

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

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

    Avec Nix

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

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

    Exemple 4 : personnaliser des dépendances

    Scénario

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

    Avec les outils classiques

    Bienvenue en enfer… Quelques « solutions » classiques :

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

    Avec Nix

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

    opencv3gtk = pkgs.opencv3.override { enableGtk2 = true; };
    

    Quelques rappels sur Nix

    Présentation

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

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

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

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

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

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

    Quelques commandes Nix

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

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

    Projet d’exemple (C++/Python)

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

    checkerboard

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

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

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

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

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

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

    Configuration Nix basique

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

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

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

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

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

    nix-env -f . -i checkerboard

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

    nix-shell

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

    nix-shell --pure --run test_checkerboard

    Configuration Nix modulaire

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

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

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

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

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

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

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

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

    nix-shell -A checkerboard
    nix-env -f . -iA checkerboard

    Configuration Nix pour un paquet Python

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

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

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

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

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

    Conclusion

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

    Lire les commentaires

  • Rejoindre le labo, entrer en contact avec la communauté (Laboratoire Linux SUPINFO)

    Si vous êtes à Caen, Clermont Ferrand, Lyon, Paris ou Rennes, il existe déjà des étudiants qui travaillent en local que vous devriez contacter (cf. le guide des labo de l'an dernier pour retrouver les contacts). Vous devriez aller vous inscrire sur le site de votre campus que vous retrouverez dans cette liste.

    Si vous êtes le premier étudiant de ce labo sur votre campus, vous pouvez créer un compte ici même. Si de nombreux étudiants se joignent à vous, il vous sera possible de demander l'ouverture d'un site dédié.

    Pour communiquer, nous vous recommandons de rejoindre le réseau de messagerie instantannée décentralisé XMPP, qui repose sur une liste d'amis permanente. Le salon de discussion du labo est : labo-linux@conference.labo-linux.org

    Si vous n'avez pas de compte, vous avez la possibilité d'en créer un sur http://xmpp.labo-linux.org Ce client Web offre une interface Responsive pour téléphones ainsi qu'un réseau social. Il existe des clients lourds tels que Gajim, Pidgin ou Adium.

     

    image

  • 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

  • Nvidia espionne ses clients par défaut (Journaux LinuxFR)

    Sous prétexte d'aider à déboguer ses pilotes lors des crashs, Nvidia vient d'imposer – sans possibilité d'opt-out – l'installation de modules de télémétrie qui remontent automatiquement et régulièrement des informations personnelles à la société, à des fins commerciales.

    Source Hardware.fr

    1. CONSENT TO COLLECTION AND USE OF INFORMATION

    Customer hereby acknowledges that the SOFTWARE accesses and collects both non-personally identifiable information and personally identifiable information about Customer and CUSTOMER SYSTEM as well as configures CUSTOMER SYSTEM in order to

    (a) properly optimize CUSTOMER SYSTEM for use with the SOFTWARE,
    (b) deliver content through the SOFTWARE,
    (c) improve NVIDIA products and services, and
    (d) deliver marketing communications.

    Information collected by the SOFTWARE includes, but is not limited to, CUSTOMER SYSTEM'S
    (I) hardware configuration and ID,
    (II) operating system and driver configuration,
    (III) installed games and applications,
    (IV) games and applications settings, performance, and usage data, and
    (IV) usage metrics of the SOFTWARE.

    To the extent that Customer uses the SOFTWARE, Customer hereby consents to all of the foregoing, and represents and warrants that Customer has the right to grant such consent.

    Dans sa politique de confidentialité, Nvidia déclare récupérer les noms, adresses postales, adresses de courriels, numéros de téléphone, adresses IP, les divers identifiants de sites sociaux et autres, et partager ces informations avec ses partenaires, revendeurs, affiliés, fournisseurs, et autres. Ces informations sont croisées avec les données liées au surf sur Internet et les données des cookies, et sont utilisées par Nvidia ou des réseaux publicitaires.

    When you use our Services, we may collect "Personal information," which is any information that can be used to identify a particular individual which can include traditional identifiers such as name, address, e-mail address, telephone number and non-traditional identifiers such as unique device identifiers and Internet Protocol (IP) addresses….

    We may from time to time share your Personal Information with our business partners, resellers, affiliates, service providers, consulting partners and others in order to provide our Services to you.

    We also permit third party online advertising networks and social media companies to collect information about your use of our website over time so that they may play or display ads that may be relevant to your interests …

    We may combine personal information that we collect about you with the browsing and tracking information collected by these technologies. We or the online advertising networks use this information to make the advertisements you see online more relevant to your interests.

    Canard PC Hardware (dans son numéro 29) a dévoilé que Nvidia procédait de la sorte depuis le pilote 368.25 à partir du moment où Geforce Experience était installé (il est désormais obligatoirement inclus avec le pilote, et nécessite une authentification), et que les données transmises n'étaient pas chiffrées, et diverses analyses de trames ont depuis montré que Nvidia collectaient bien plus que des données nécessaires à l'analyse des crashes.

    Procédons donc à l'innocente installation du dernier driver en date de Nvidia (368.25). Dès le début du processus, le programme s'empresse d'envoyer – en HTTP non chiffré – les versions des pilotes que vous vous apprêtez à installer, accompagné du PCI ID de votre carte graphique, à gfswl.geforce.com. Après quelques informations de seconde importance (ID, taille du moniteur, etc.) transmises à Adobe et un inévitable tracker Google Analytics, Nvidia se permet tranquillou d'envoyer des informations hardware basiques sur votre machine – comme le modèle de votre CPU ou de votre SSD – sur telemetry.Nvidia.com. Intolérable ? S'il n'y avait que ça…

    Si vous avez eu le malheur de laisser s'installer GeForce Experience (par défaut), celui-ci en profite pour envoyer l'intégralité des informations matérielles détaillées de votre PC quelques minutes plus tard à gfe.Nvidia.com/getsugar (notez le cynisme de l'URL) : marque et modèle de la carte mère, numéro de série de votre machine, version du BIOS, clés USB connectées, taille de le RAM, fréquence du GPU, etc. Scandaleux ? Attendez, attendez, ce n'est pas tout !

    GeForce Experience envoie aussi la liste des applications que vous utilisez (jeux ou pas), le moment où vous les lancez, les arrêtez et, s'il s'agit d'un jeu, un historique du frame rate mesuré (avec valeur mini/maxi) ainsi que sa configuration et des statistiques diverses.

    Votre dernière partie de 3D SexVilla était-elle bien fluide sur votre GTX 960 ? Nvidia le sait, lui. Et il sait également où vous avez cliqué sur ses utilitaires, combien de temps vous avez passé sur chaque page, etc. En tout, près de 100 Ko d'informations (accompagnées de trackers Google qui s'exécutent très régulière-
    ment) sont ainsi transmises à Nvidia. Un log déchiffré que nous avons intercepté sur notre machine de test est disponible ici : cpc.cx/fN6.

    Ce genre de pratique constitue une atteinte évidente à la vie privée. Alors certes, les conditions d'utilisation en anglais de Nvidia sont parmi les plus intrusives qui soient, puisqu'en les acceptant, vous autorisez le fabricant à récupérer des informations "personnelles ou non" et à les partager avec des tiers. En revanche, la version française accessible par un lien au moment de télécharger le pilote ne mentionne aucunement ces récupérations de données privées massives. Une preuve de plus du peu de cas que semble faire Nvidia de la vie privée de ses utilisateurs…

    Je n'ai pas trouvé d'information sur le fait que les pilotes pour Linux soient concernés. A priori pas, puisque les pilotes sont en retard par rapport à Windows, et que Geforce experience n'est pas (encore ?) disponible sous Linux.

    Toujours est-il que je me demande comment va réagir l'Union Européenne, alors que cette pratique, sans possibilité d'opt-out, semble être clairement interdite.

    Et puis…

    « Toute personne a droit au respect de sa vie privée et familiale, de son domicile et de sa correspondance. » – Convention européenne des droits de l'homme – Article 8

    Lire les commentaires

  • Wayland et Weston 1.4 (Dépêches LinuxFR)

    Wayland et Weston sont sortis en version 1.4 le jeudi 24 janvier. Sous GNU/Linux et BSD (et d’autres…), lorsqu’une application veut afficher quelque chose à l’écran, elle doit utiliser le protocole X11 pour communiquer avec X.org, qui se charge de faire l’affichage. Or, ces derniers sont très vieux et ne sont pas adaptés au matériel moderne.

    X.org a été conçu à une époque où l’on utilisait peu la carte graphique. Aujourd’hui, nos navigateurs web (rendu HTML, CSS, JavaScript…) et nos interfaces graphiques (Qt, Cairo…) ont de nombreuses occasions de solliciter celle-ci, sans compter que l’arrivée de Steam a permis l’arrivée de nombreux titres pour notre OS favori.

    Côté sécurité, X.org est une vraie passoire : écrire un enregistreur de clavier est un jeu d’enfant… Wayland devrait changer ça, mais cela ne signifie pas la fin des failles : par exemple, l’arrivée de WebGL (et bientôt de WebGL 2 ! cf. ici et ) dans nos navigateurs web ouvre potentiellement de nouvelles failles dans nos systèmes, d’autant plus que les pilotes graphiques eux-mêmes n’ont souvent pas été conçus dans une optique principale de sécurité, mais c’est un autre problème.

    Mais alors, qu’est-ce que Wayland et Weston ?

    Sommaire

    Rappels sur Wayland et Weston

    Wayland est un protocole de serveur d’affichage destiné à remplacer X11 (sans ses défauts). Il a le soutien officiel des développeurs X11/X.org. Weston est une implémentation de référence de Wayland (pour la démonstration, mais il se pourrait qu’on le retrouve utilisé tel quel, notamment dans l’embarqué).

    Côté développeur, seules quelques briques logicielles devront être adaptées (toutes les bibliothèques d’interfaces graphiques et certaines applications utilisant des fonctions graphiques de bas niveau). Une particularité de Wayland est que le protocole doit être implémenté dans le compositeur (qui est souvent également le gestionnaire de fenêtres : Kwin, Mutter, etc), ce qui permet d’éviter les couteuses communications entre X.org et le compositeur pour le rendu. Le protocole est également plus simple.

    Les développeurs de Wayland/Weston sont majoritairement des développeurs de X.org. Ils sont donc tout à fait au courant des failles de X.org, et ne veulent pas les corriger car cela impliquerait un travail titanesque, et un changement d’API considérable qui obligerait beaucoup de développeurs à récrire leurs bibliothèques/applications pour prendre en compte les modifications. En repartant de zéro, il est possible de construire un modèle de sécurité solide. (Source)

    Enfin il sera toujours possible d’utiliser les applications qui n’auront pas migré grâce à XWayland (qui permet de faire tourner X.org à l’intérieur de Wayland). Malgré l’utilisation d’une couche supplémentaire (Wayland + XWayland au lieu de X.org tout seul), on attend des performances similaires voire meilleures (car on profite des améliorations de Wayland).

    Pour mieux comprendre ce que sont Wayland et Weston, vous pouvez lire la série de dépêches « X.Org est mort, vive Wayland ! » dont les liens sont disponibles en première partie de dépêche.

    OpenGL

    Les bibliothèques et pilotes OpenGL sous GNU/Linux dépendent de X.org, c’est pourquoi Wayland n’utilise pas OpenGL mais OpenGL ES (plus souvent implémenté pour l’instant dans les pilotes graphiques des puces pour smartphones et tablettes. Toutefois les puces Intel, par exemple, bénéficient de la prise en charge d’OpenGL ES à partir des CPU de génération Sandy Bridge, c-a-d à partir des puces graphiques Gen6 dans la nomenclature du fondeur). À long terme, on pourra utiliser de l’OpenGL « classique » sous Wayland.

    Linux

    Pour afficher des messages à l’écran, le noyau était déjà obligé de s’occuper de la gestion du mode d’affichage (résolution, fréquence de rafraichissement, profondeur de couleur), qui était alors réinitialisé lors du chargement du pilote pour X.org. Au final, il y avait des problèmes de lenteur lors du changement entre session graphique et terminaux virtuels et de mauvaises résolutions dans ces derniers.

    KMS a alors été intégré au noyau pour gérer cela bien avant le lancement de la session graphique, ce qui est non seulement plus efficace mais évite en plus les clignotements lors du chargement du pilote. Il y a donc une partie du pilote pour le noyau (pilotes [nom_du_pilote]-dri), et la partie X.org (xf86-video-[nom_du_pilote_]).

    Avec Wayland, les pilotes X.org ne seront plus nécessaires, réduisant la quantité de code à maintenir.

    Démonstration

    Il y a plein de vidéos de démonstration disponibles, mais il y en a une en particulier que je tiens à vous montrer, car elle est vraiment originale. En effet, c’est la vidéo d’un compositeur Wayland un peu spécial

    Bref, on peut faire des trucs vraiment sympathiques avec Wayland. ;)

    Prise en charge de Wayland

    Boites à outils

    Wayland est déjà pris en charge par Qt depuis la version 5, GTK depuis la version 3, Clutter, la SDL, et les EFL. Il faut cependant garder à l’esprit que Wayland est toujours en développement, et que la gestion de Wayland n’a pas été testée à grande échelle. Il ne faut donc pas attendre la même stabilité que des systèmes qui sont basés sur un protocole inchangé depuis plusieurs dizaines d’années, mais ça fonctionne et le plus gros du travail a été fait.

    Environnements de bureau

    La gestion de Wayland dans KDE est prévue pour l’été 2014, à partir de la sortie de KDE Frameworks 5. KDE Frameworks 5 est la nouvelle génération de kdelibs (migration vers Qt5, nettoyage de code, modularisation), commencée au printemps 2011. Toute application KDE utilisant les nouvelles bibliothèques ne nécessitera que peu de changements pour fonctionner, à l’exception notable de Kwin qui utilise de nombreuses fonctions bas niveau.

    GNOME Shell, l’environnement de bureau des canards, gère Wayland depuis GNOME 3.10 mais on attend une bien meilleure prise en charge pour GNOME 3.12.

    Canonical n’a pas l’intention d’ajouter la prise en charge de Wayland à Unity. En effet, ils développent leur propre solution pour remplacer X.org, Mir.

    Enlightenment prend partiellement en charge Wayland depuis la version 0.18, la prise en charge complète arrivera avec la version 0.19.

    Hawaii est un nouvel environnement de bureau, parce que les gouts et les couleurs… Il fait partie d’un projet de nouveau système d’exploitation, Maui, conçu à l’image d’elementary OS et Pantheon (et Ubuntu/Unity?) pour réaliser un système cohérent et sans problèmes. Il est conçu sur des technologies modernes telles que systemd, Wayland et Qt5 (là où elementary OS a fait le choix de technologies GNOME comme GTK).

    Une très bonne nouvelle pour les utilisateurs de gestionnaires de fenêtres légers, il sera possible de migrer vers Wayland sans écrire un compositeur complet grâce à SWC, une bibliothèque qui fait moins de 6 000 lignes de code et qui « a pour but d’embarquer le strict minimum pour afficher des fenêtres sur l’écran. »

    Nouveautés

    Voici une liste des nouveautés introduites au sein de Wayland et Weston, traduction de l’annonce sur la liste de diffusion du projet.

    Wayland

    • Protection des tampons SHM contre le signal SIGBUS.
      Des fonctions utilitaires ont été ajoutées pour aider les compositeurs à se protéger contre des clients dysfonctionnels ou malveillants qui tronqueraient le fichier sous-jacent aux tampons SHM et déclencheraient un signal SIGBUS. (Neil Roberts)

    • Le protocole Subsurfaces a intégré le dépôt Wayland et fait donc partie officiellement du protocole Wayland (Pekka Paalanen). Une description est disponible ici : http://ppaalanen.blogspot.fr/2013/11/sub-surfaces-now.html

    • wl_proxy_set_queue() accepte une file d’attente (queue en anglais) NULL pour se réinitialiser sur celle par défaut. (Neil Roberts).

    • Quelques corrections de bug. Notamment une situation de concurrence entre wl_proxy_create() et wl_proxy_marshal().

    • Quelques améliorations sur les messages d’erreur liés au scanner et des ajustements de la documentation.

    Weston

    • Des boutons dans les fenêtres XWayland et des décorations correctes pour le compositeur imbriqué (moteur Wayland). (Jason Ekstrand)

    • Conversion de gl-render en module chargeable et ajout de la possibilité de passer de pixman à gl-render durant l’exécution. Cela permet un chargement du compositeur plus rapide, puisque gl-render et EGL+GLES2 peuvent être chargés et initialisés plus tard lors de la phase de démarrage (Ander Conselvan de Oliveira).

    • Utilisation de logind pour l’accès privilégié (accès à la carte graphique — via le composant DRM du noyau — et aux périphériques d’entrée). weston peut donc utiliser KMS sans bidouillage. (David Herrmann)

    • Meilleure gestion du débranchement de sortie. En effet, cela vautrait weston car le débranchement de sortie (moniteur) n’était simplement pas pris en charge. Nous nettoyons désormais les choses de façon appropriée et nous faisons revenir les fenêtres dans la région visible quand leur sortie est débranchée. (Ander Conselvan de Oliveira and Xiong Zhang)

    • Animation du focus du clavier et exposay (aperçu de fenêtres de type exposé) contribué par Collabora.

    • Meilleure prise en charge des écrans tactiles, incluant le toucher-déplacer et le toucher-activer pour les surfaces, et le glisser-déposer. (Xiong Zhang)

    • Début du travail sur le protocole xdg-shell. C’est une tentative plus formelle de développer un protocole pour l’interaction entre les applications et un environnement de bureau. Le protocole wl_shell actuellement présent dans Wayland a toujours été un développement temporaire pour aider au démarrage de la prise en charge par les bibliothèques d’interfaces graphiques. Maintenant que GNOME Shell migre sur Wayland, nous avons un environnement de bureau complet pour orienter le travail et nous pouvons commencer les choses sérieuses. (Jasper St. Pierre, Rafael Antognolli)

    • Passage de tampon à travers un compositeur imbriqué. Nous avons spécifié une nouvelle extension EGL qui permet de faire passer des tampons à travers un compositeur imbriqué. Ceci permet au compositeur imbriqué de ne pas faire le rendu et à la place de présenter le contenu au compositeur sous-jacent en utilisant une subsurface ou autre (Neil Roberts).

    • Protocole de rognage et de mise à l’échelle. Ce protocole, que nous avions initialement mis en place dans weston, permet à un client de spécifier que seul un sous-rectangle de sa surface doit être présenté, et potentiellement agrandi. (Jonny Lamb and Pekka Paalanen)

    • Dans weston-terminal, on peut utiliser Ctrl+Maj ↑/↓ pour défiler et voir l’historique de la sortie du terminal. Ajout d’un menu contextuel pour un accès simple au Copier/Coller/Nouveau Terminal (qui ont toujours été accessibles via Ctrl-Maj-C/V/N). (Kristian Høgsberg). Prise en charge de la sélection avec un écran tactile. (Xiong Zhang)

    La suite

    DRI3, qui vient d’intégrer la version 1.15 de X.Org Server, ne figure pas encore dans cette livraison, et nous attendons symétriquement l’intégration de XWayland dans X Server qui, comme nous l'avons vu, permettra à Wayland de faire tourner les applications X11 classiques qui n'auront pas été adaptées.

    Lire les commentaires