Le collectif « Convergences Numériques », qui regroupe dix organisations professionnelles du numérique françaises, dont Numeum et le Cigref (mais pas le CNLL), avait organisé jeudi dernier une soirée pour à la fois présenter un « manifeste » concernant la politique européenne du numérique, et pour auditionner 7 représentants des listes candidates aux élections européennes de juin prochain.

Sur les 10 pages du manifeste, une seule proposition concerne le logiciel libre: « Encourager l’Europe à soutenir l’open source : largement adopté par les entreprises et administrations françaises, l’open source est un atout majeur pour répondre aux défis de l’indépendance technologique et de la transition écologique. » C'est peu, compte-tenu notamment du fait que le logiciel libre représente plus de 10% du chiffre d'affaire annuel de la filière informatique (logiciels et services) en France et un peu moins de 10% en Europe (source: étude Markess 2022 pour le CNLL, Numeum et Systematic), et que la stratégie de la Commission pour l'Open Source s'arrête à 2023.

Lors des auditions, seuls deux candidats ont parlé du logiciel libre, y consacrant chacun l'essentiel de leur temps de parole: Sven Franck, co-tête de liste du parti Volt, et Pierre Beyssac, numéro 2 de la liste du Parti Pirate. Sven Franck a notamment présenté l'intérêt du logiciel libre pour la souveraineté et la compétitivité européennes, et Pierre Beyssac l'importance d'une forme de souveraineté numérique « personnelle » en plus d'une vision plus « étatique » de la souveraineté.

Notons enfin que le CNLL a publié en mars un questionnaire adressés aux partis politiques qui souligne l'importance stratégique du logiciel libre pour la souveraineté numérique, l'innovation et les valeurs démocratiques de l'Europe. Il invite les candidats à partager leur vision et leurs propositions sur un large éventail de sujets liés au logiciel libre, notamment la gouvernance numérique, l'éducation et la formation, le soutien aux PME, l'innovation, les politiques spécifiques et la collaboration. Les questions portent sur des aspects concrets tels que la promotion du logiciel libre dans l'administration publique, l'accès aux marchés pour les PME, les programmes de financement, l'interopérabilité, l'inclusion sociale et la durabilité numérique.

À ce jour, aucune réponse n'a été reçue (malgré de multiples relances), et seuls Volt et le Parti Pirate se sont engagés à répondre. Notons pour finir que des propositions en faveur du logiciel libre sont détaillées dans leurs programmes (cliquez sur "lire la suite" pour en savoir un peu plus).

À propos des programmes des partis

Les propositions relatives au logiciel libre du programme du Parti Pirate se trouvent sur cette page et celles de Volt dans ce PDF (p. 73).

Les deux partis vont dans le même sens d'un soutien affirmé au logiciel libre, mais le Parti Pirate entre davantage dans les détails et propose un programme plus exhaustif et radical de transition vers l'open source, là où Volt en reste à des propositions plus générales. Les motivations mises en avant diffèrent également en partie.

Convergences

Les programmes de Volt et du Parti Pirate concernant le logiciel libre présentent plusieurs points de convergence:

1. Les deux partis soutiennent la publication sous licence open source des logiciels développés grâce à des fonds publics, afin de garantir leur transparence et leur réutilisation.
2. Ils souhaitent tous deux promouvoir l'utilisation de logiciels libres et formats ouverts dans l'administration publique.
3. Ils proposent de soutenir financièrement le développement de l'écosystème du logiciel libre et des technologies open source.
4. Ils veulent éviter de rendre de facto obligatoire l'usage de formats propriétaires dans les communications avec l'administration.

Différences

1. Le Parti Pirate va plus loin dans les détails et les mesures concrètes proposées (migration du secteur public vers le libre, création d'OSPO dans les États membres, licences copyleft, compatibilité multi-plateformes des logiciels publics, accès aux données publiques…).
2. Le Parti Pirate insiste davantage sur les enjeux de transparence, d'autonomie et de vie privée des utilisateurs, tandis que Volt met plus l'accent sur la pérennité de l'écosystème.
3. Le Parti Pirate veut éviter de soumettre le développement de logiciel libre aux mêmes contraintes que le logiciel propriétaire, point qui n'est pas abordé par Volt.
4. Volt propose de responsabiliser les intégrateurs sur la conformité des logiciels libres déployés, ce qui n'apparaît pas dans le programme du Parti Pirate.

Les propositions des autres partis

À ce jour, et malgré des dizaines de courriels envoyés aux autres partis, nous n'avons pas identifié de propositions concernant le logiciel libre dans les programmes des autres partis. Si vous avez des contacts au sein de ces partis, n'hésitez pas à relayer cette information. Une nouvelle dépêche sera publiée si nous arrivons à obtenir des réponses.

GValiente développe un SDK pour créer des jeux pour la console Game Boy Advance : Butano.

Cet entretien revient sur son parcours et les raisons qui l’ont amené à s’intéresser à cette console.

Sommaire

• • Partie 1: présentation
    • Qui êtes-vous, quel est votre parcours et est-il lié aux jeux vidéos ?
    • Pourquoi le retrogaming est-il important pour vous ?
  • Partie 2: Game Boy Advance
    • Comment en êtes-vous venu à vous intéresser à la Game Boy Advance ?
    • Qu’est-ce que cette console a de particulier ?
    • Est-elle proche de la Game Boy ou de la SNES ?
    • Comment fonctionne l'affichage (PPU, écran LCD) ?
    • La console peut-elle faire de la 3D ?
    • Comment fonctionne le son ?
    • Comment marche la rétrocompatibilité avec les précédentes Gameboy ?
    • La machine possède une ROM interne, à quoi sert-elle ?
    • La GB possède un dispositif anti piratage, comment fonctionne-t-il ?
    • Comment fonctionne le réseau (Game Boy Link) ?
    • Les cartouches peuvent-elles embarquer des coprocesseurs ?
    • Les émulateurs sont-ils bons ?
    • Quels sont vos jeux commerciaux préférés sur cette console ?
    • Quels sont vos jeux "homebrew" préférés sur cette console ?
  • Partie 2 : Butano
    • Pourquoi créer un SDK aujourd’hui pour si vieux système ?
    • Est-ce que vous participez vous même à la création de jeux ?
    • Quels ont été les difficultés pour créer Butano ?
    • Vous aimeriez vivre du développement de ce logiciel libre?
    • Est-ce que Butano gère les accessoires (e-Reader, WormCam, Play-Yan…) de la console ?
    • Quels conseils donneriez-vous à quelqu’un qui veut se lancer dans le développement de jeux Game Boy Advance ?
    • Quels sont les outils pour créer/préparer des graphismes utilisable par Butano ?
    • Quels sont les outils pour créer/préparer des musiques et des sons utilisable par Butano  ?
    • Est-il possible de créer ses propres cartouches ?
    • Pourquoi le choix de C++ pour ce SDK ?
    • Est-ce qu'il existe d'autres SDK libres pour ces consoles ?
  • Partie 3: pour finir
    • En dehors du travail, quels logiciels libres utilisez-vous, sur quel OS ?
    • Au travail, quels logiciels libres utilisez-vous, sur quel OS ?
    • Quelle est votre distribution GNU/Linux préférée et pourquoi, quels sont vos logiciels libres préférés ?
    • Quelle question auriez-vous adoré qu’on vous pose ?
    • Quelle question auriez-vous détesté qu’on vous pose ?

Partie 1: présentation

Qui êtes-vous, quel est votre parcours et est-il lié aux jeux vidéos ?

Après des études d'informatique, j'ai travaillé dans plusieurs domaines autour du logiciel comme les pages web ou les applications graphiques Java/Swing.

Aujourd'hui je travaille plutôt en C et C++ dans l'embarqué, ainsi même si mon parcours professionel n'est pas directement lié aux jeux vidéos, mon boulot actuel en est plutôt proche.

Comme loisir, j'ai joué un peu avec RPG Maker 2K avant de commencer à programmer pour la GBA.

Pourquoi le retrogaming est-il important pour vous ?

D'abord pour la nostalgie : être capable de jouer à nouveau aux jeux de votre enfance est très important pour tout le monde. Malheureusement, pouvoir rejouer à de vieux jeux est quelque chose que nous sommes en train de perdre à cause des restrictions des jeux modernes (mode en ligne obligatoire, DRM…).

Ensuite, grâce aux émulateurs il est très facile de lancer sans problème des jeux que j'ai créés pour la GBA il y a 20 ans. Si je les avais fait pour Mandrake 8.0 à la place, ce ne serait pas aussi facile de les tester aujourd'hui sans recompiler du vieux code et autre.

Partie 2: Game Boy Advance

Comment en êtes-vous venu à vous intéresser à la Game Boy Advance ?

La GBA SP était un grand progrès par rapport au modèle original grâce à l'écran rétro-éclairé et la batterie intégrée, alors j'en ai acheté une dès qu'elle est sortie.

Les jeux 2D me manquaient après la N64 et la GameCube, alors pouvoir jouer à des classiques de la 2D comme Final Fight sur une console portable était génial.

Mais ce qui m'intéressait vraiment à propos de la GBA était la possibilité de créer des jeux grâce au HAM SDK et aux flashcarts.

Qu’est-ce que cette console a de particulier ?

C'est la dernière console 2D. Le système graphique de la GBA fonctionne comme les consoles 16 bits classiques comme la SNES ou la Megadrive, avec des sprites, des arrières plans…

Toutefois elle utilise un processeur ARM 32 bits tourant à 16MHz, alors il n'est plus nécessaire ou aussi important de programmer en assembleur pour avoir de bonnes performances.

En plus, je trouve plus "magique" de voir votre jeu tourner sur un écran d'une vieille console portable que sur un écran de télévision.

Est-elle proche de la Game Boy ou de la SNES ?

Au niveau graphique, c'est comme une SNES avec plus de couleurs simultanées, plus d'arrière plans et beaucoup de sprites par scanline (proche d'une Neo Geo et en plus on peut leur appliquer une rotation !). Elle permets aussi d'utiliser un "framebuffer" qui rends le rendu "logiciel" plus facile. Les jeux 3D comme Doom sont beaucoup plus rapide sur la GBA grâce à ces modes. Malheureusement la résolution de l'écran est un peu trop basse (240x160 contre 256x224 pour la SNES par exemple).

Cependant, au niveau son, c'est pire que la SNES: la GBA partage le même canal PSG que la Game Boy originale avec deux nouveaux canaux directs pour jouer des samples PCM. Avoir seulement deux canaux PCM demande presque toujours de gâcher des tonnes de cycles CPU en mixage audio et même après cela sonne toujours pire que la SNES.

Comment fonctionne l'affichage (PPU, écran LCD) ?

Comme je l'ai dit, cela fonctionne comme une SNES : vous avez un nombre fixe d'arrière plans et de sprites, vous les configurez en écrivant des registres. La GBA a aussi des interruptions HDMA et H-Blank, donc vous pouvez faire beaucoup d'effets "raster" comme le fameux mode 7 de la SNES.

Néanmoins, quelques limitations pénibles du PPU de la SNES ont été retiré, ce qui rends le PPU de la GBA plus facile à programmer. Par exemple, la GBA permets d'écrire en VRAM pendant le "V-Draw" (quand le PPU rafraîchit l'écran). Cela permets d'utiliser toutes les tailles de sprites disponibles en même temps alors que la SNES ne permettait que deux tailles simultanément.

La console peut-elle faire de la 3D ?

La GBA n'a pas d'accélération 3D matérielle, mais son CPU est assez rapide pour faire du rendu logiciel (à un faible taux de rafraîchissement). Il y a quelques techniques pour dessiner des polygones 3D avec des sprites 2D, mais cela vient avec des tonnes de limitations. Dans Varooom 3D, j'ai utilisé des sprites 2D poour dessiner des lignes horizontales, ce qui m'a permis de dessiner quelques polygones non texturés à 60 images par seconde.

Comment fonctionne le son ?

Je ne sais pas très bien comment fonctionne l'audio de la GBA, car je n'en ai pas eu besoin : il y a de très bonnes bibliothèques disponibles et j'ai préféré les intégrer plutôt que d'implémenter ma propre solution.

Comment marche la rétrocompatibilité avec les précédentes Gameboy ?

Il y a 3 modèles de GBA disponible: GBA, GBA SP and GBA Micro. Seules les deux premières sont compatibles avec la Game Boy originale.
La rétrocompatibilité est transparente pour le développeur et la plupart des fonctionnalités de la Game Boy sont indisponibles en mode "natif" : un jeu GBA ne peut pas utiliser le CPU de la Game Boy par exemple.

La machine possède une ROM interne, à quoi sert-elle ?

La GBA démarre depuis le BIOS, une petite ROM qui montre l'écran d'accueil et exécute le jeu après cela. Il a aussi quelques fonctions liées à l'énergie, comme arrêter le CPU jusqu'au V-Blank ou mettre la console en veille. Enfin, il propose quelques routines comme des fonctions mathématiques, mais je ne les utilise pas pour des questions de performances. Cela aide aussi à éviter les bugs d'émulation du BIOS.

La GB possède un dispositif anti piratage, comment fonctionne-t-il ?

Je préfère vous renvoyer à l'article de copetti.org sur le sujet.

Comment fonctionne le réseau (Game Boy Link) ?

Comme pour l'audio, je ne sais pas trop comment cela fonctionne, car j'ai préféré intégrer une bibliothèque.
En général je préfère une bonne bibliothèque plutôt que passer du temps à implémenter une plus mauvaise solution.

Les cartouches peuvent-elles embarquer des coprocesseurs ?

Bien sûr, mais le CPU est tellement puissant par rapport à ceux des consoles 16 bits, qu'il n'y en a pas souvent besoin. Le meilleur exemple d'une cartouche officielle avec un coprocesseur dont je me rappelle est la Play-Yan : elle semble embarquer un VideoCore 1 pour jouer des musiques mp3 et des vidéos mp4 depuis une carte SD.

Les émulateurs sont-ils bons ?

Extraordinaires. Les émulateurs GBA sont si bons que vous n'avez presque jamais besoin de tester sur du vrai matériel. Si votre jeu fonctionne sur la plupart des émulateurs modernes, alors votre jeu a toutes les chances de fonctionner sur une console réelle sans souci. D'ailleurs la plupart des membres actifs de gbadev ne possèdent même pas de GBA.

Quels sont vos jeux commerciaux préférés sur cette console ?

Beacoup :

• des joyaux de Treasure comme Astro Boy Omega Factor et Gunstar Super Heroes ;
• d'autres jeux d'action comme Ninja Five-0, Dragon Ball Advanced Adventure et Final Fight ;
• tous les Castlevanias (qui sont proches du Simphony of the Night de la PS1) ;
• les ports de Doom ;
• bien sûr les classiques de Nintendo comme Wario Ware et Zelda the Minish Cap ;
• des RPGs bien connus comme Mother 3, Mario and Luigi et Final Fantasy I&II ;
• quelques RPGs moins connus comme Riviera et CIMA the Enemy.

Quels sont vos jeux "homebrew" préférés sur cette console ?

Il y en a beaucoup aussi, mais mon préféré est de loin GBA Microjam '23: c'est une collection de mini jeux très amusants à la Wario Ware.
Ce qui le rend très spécial, c'est que chaque mini-jeu a été fait par un membre différent de gbadev, c'est un jeu "communautaire".

D'autres très bons:

• Goodboy Galaxy ;
• Demons of Asteborg DX ;
• GBADoom, un portage opensource de Doom ;
• SNESAdvance ;
• OpenLara ;
• Super Wings ;
• Symbol Merged ;
• Anguna
• Vulkanon ;
• Inheritors of the Oubliette ;
• Demoscene entries like all Shitfaced Clowns prods ;
• et les jeux que j'ai fait bien sûr.

Partie 2 : Butano

Pourquoi créer un SDK aujourd’hui pour si vieux système ?

L'objectif de Butano était de pouvoir travailler avec le PPU de la GBA et le reste du système aussi facilement que possible sans perdre trop de cycles CPU. Et je pense que j'y suis arrivé : avec Butano, vous pouvez créer, afficher et détruire des sprites, des arrière plans, du texte, des effets raster et plus encore avec une seule ligne de C++.

Les prémisses de Butano étaient une bibliothèque interne à mes jeux. Je n'avais pas de plan pour rendre ça public à part faire quelques exemples et de la documentation.

Finalement je suis content d'avoir rendu ça public : le plus grand accomplissement de Butano est le grand nombre de jeux de qualité fait avec.

Est-ce que vous participez vous même à la création de jeux ?

Oui, Butano vient avec le code source de deux jeux que j'ai fait : Butano Fighter et Varooom 3D.

Quels ont été les difficultés pour créer Butano ?

Pour être honnête, je n'ai pas eu beaucoup de difficultés grâce au grand nombre de bibliothèques, tutoriaux, émulateurs et outils disponibles pour la GBA.

Vous aimeriez vivre du développement de ce logiciel libre?

Bien sûr, mais à moins de travailler à plein temps sur un jeu homebrew à grand succès, c'est difficile voire impossible de vivre de ça.

Est-ce que Butano gère les accessoires (e-Reader, WormCam, Play-Yan…) de la console ?

Il gère les accessoires les plus communs : SRAM, rumble et l'horloge temps réel / real time clock (RTC).

Pour les accessoires plus exotiques, je pense qu'il est préférable d'utiliser d'autres bibliothèques.

Quels conseils donneriez-vous à quelqu’un qui veut se lancer dans le développement de jeux Game Boy Advance ?

Premièrement, vous devez apprendre les bases du C/C++ : la plupart des nouveaux connaissent uniquement des langages de haut niveau comme Javascript ou Python, malheureusement ils sont un peu trop lourds pour la pauvre GBA.

Après, vous pouvez suivre cet excellent guide plutôt que suivre mes modestes conseils.

Quels sont les outils pour créer/préparer des graphismes utilisable par Butano ?

J'utilise Gimp et Usenti (un logiciel proche de MS Paint pour la GBA et notamment une gestion des couleurs 15 bits et des palettes). Toutefois, la plupart des outils permettant de produire des images indexées peuvent faire l'affaire.

Pour le travail des cartes, j'aimais utiliser Tiled par le passé.

Quels sont les outils pour créer/préparer des musiques et des sons utilisable par Butano  ?

OpenMPT est l'outil audio le plus populaire pour la GBA, les musiques étant généralement créées avec un tracker. Il a aussi de bons outils pour travailler avec les samples. D'autres utilisent hUGETracker et Furnace.

Est-il possible de créer ses propres cartouches ?

Je ne suis pas juriste, mais comme Butano est sous licence zlib, tant que vous respectez cette licence et celles des autres dépendances, vous pouvez faire vos propres cartouches et même les vendre.

Je pense que ce que font la plupart des gens aujourd'hui, c'est acheter des cartouches pirates Pokémon pas chères, et les flasher pour y mettre leurs propres jeux.

Pourquoi le choix de C++ pour ce SDK ?

Comme je l'ai dit, un langage de haut niveau avec ramasse miettes est généralement trop pour la GBA.

Entre C et C++, j'ai choisi ce dernier, car il permet de réduire grandement la quantité de code sans gâcher trop de CPU.

Par exemple:

• les destructeurs de C++ permettent de ne pas avoir à écrire trop de code pour nettoyer les ressources, ce qui est une source de bugs importante sur les grands projets GBA ;
• la GBA ne gère pas les nombres flottants en hardware, donc utiliser des nombres en virgule fixe est essentiel. Grâce à la surcharge d'opérateurs, C++ permets d'écrire des classes qui se comportent comme des nombres flottants.
• L'opérateur constexpr permet de générer et stocker des tables de correspondance (lookup tables) ou autres constantes en ROM sans avoir à utiliser d'outils externes.

Est-ce qu'il existe d'autres SDK libres pour ces consoles ?

Il y a beaucoup de SDK pour GBA, mais malheureusement (à mon avis) la plupart sont de plus bas niveau que Butano.

Voici une liste de ressources (compilers, toolkits, libraries, etc.) pour la GBA: resources GBA.

Partie 3: pour finir

En dehors du travail, quels logiciels libres utilisez-vous, sur quel OS ?

J'utilise généralement Windows à cause du boulot et de certains jeux PC, mais la plupart des programmes que j'utilise sont libres.

L'éditeur de code que j'utilise presque toujours est Qt Creator, il est génial pour C++.

À part les logiciels libres pour le développement GBA, j'utilise Firefox, Notepad++, VLC, 7-Zip, LibreOffice, TortoiseGit, VirtualBox et bien sûr les émulateurs pour les vieilles consoles et bornes d'arcade.

Au travail, quels logiciels libres utilisez-vous, sur quel OS ?

Pour le développement embarqué, j'utilise GCC et les outils GNU. Pour les applications de bureau, j'utilise Qt avec MinGW.

GCC est aussi le compilateur le plus populaire pour le développement GBA, alors je n'aurais pas pu l'éviter même si j'avais voulu.

D'autres logiciels que j'utilise au travail : Thunderbird, Putty and WinSCP.

Quelle est votre distribution GNU/Linux préférée et pourquoi, quels sont vos logiciels libres préférés ?

Ubuntu est bien pour le peu d'usage de Linux que je fais.

Mes logiciels libres favoris sont ceux avec lesquels je passe le plus de temps : Firefox, Qt Creator, GCC, les émulateurs.

Quelle question auriez-vous adoré qu’on vous pose ?

Mmh… rien qui me vienne à l'esprit.

Quelle question auriez-vous détesté qu’on vous pose ?

Pourquoi perdez-vous votre temps avec des consoles vieilles de 20 ans ?

Maintenant que j'y pense… J'aurais adoré qu'on me demande ça.

Scenari est un ensemble de logiciels open source dédiés à la production collaborative, publication et diffusion de documents multi-support. Vous rédigez une seule fois votre contenu et vous pouvez les générer sous plusieurs formes : site web, PDF, OpenDocument, diaporama, paquet SCORM (Sharable Content Object Reference Model)… Vous ne vous concentrez que sur le contenu et l’outil se charge de créer un rendu professionnel accessible et responsive.

À chaque métier/contexte son modèle Scenari :

• Opale pour la formation
• Dokiel pour la documentation
• Optim pour les présentations génériques
• Topaze pour les études de cas
• …

L’association propose un mini-webinaire intitulé « Scenaristyler : ajouter son logo dans les publications PDF, web, diapo » le lundi 15 avril 2024 de 17h à 18h heure de Paris, à l’adresse https://scenari.org/visio/miniwebinaire.
Pour préparer la session, vous pouvez participer à ce fil de discussion sur le forum Scenari.

Découvrez le programme en détails, et inscrivez-vous dès maintenant aux Rencontres Scenari 2024 à l’Université Toulouse Capitole du 3 au 7 juin.

Tarifs préférentiels pour toute inscription avant le 3 mai. N’attendez pas !

L’équipe de l’UT Capitole a négocié des options de logement. Les détails sur le site des Rencontres.

Aidez-nous à diffuser l’événement et partagez l’annonce des Rencontres sur les réseaux sociaux : Mastodon, LinkedIn et Telegram.

Deux offres d’emploi autour de Scenari :

• Une offre de Sorbonne Université pour un⋅e ingénieur⋅e pédagogique devant « connaître les outils numériques de l’établissement » : Scenari entre autres.
• Une offre d’une école supérieure localisée à La Défense pour un⋅e technicien⋅ne support de plateformes pédagogiques. Le poste consiste à « administrer des environnements numériques », « suite logicielle Scenari » entre autres, et à « participer à la médiatisation des contenus en utilisant la chaîne éditoriale Scenari ».

Nouvelles versions d’outils Scenari :

• Sortie de IDKey 2 et mise à jour de OpenKeys. Retrouve les détails sur le forum.
• Nouvelle version de Topaze (4.0.7) apportant quelques corrections.
• Sortie de TechnOpale 2.2.5 (dérivé d’Opale 4.0.5). TechnOpale est une modification d’Opale destinée à l’enseignement des sciences expérimentales dans le secondaire. Les détails d’installation de la nouvelle version sont sur le forum.

Mettez à jour vos modèles dès que possible !

Le Comité Opale prévoit de se réunir en mai pour analyser les demandes d’évolution, et les passer à priorisation par les adhérent⋅e⋅s lors des Rencontres 2024 (tiens, encore une bonne raison pour adhérer :) ).

Donc si vous avez une idée d’évolution, essayez de la proposer avant mai (sinon ce n’est pas grave ça sera pour l’année prochaine).

Ça se passe sur la place des évolutions Opale (lisez les explications pour bien comprendre comment on s’y prend)

L’équipe de traduction communautaire vers l’italien a été constituée.

Si vous pouvez donner un coup de main pour traduire du français vers l’italien (chacun⋅e en fonction de ses disponibilités), écrivez à direction@scenari.org.

Ainsi nos amis transalpins pourront utiliser aussi les outils Scenari dans leur langue.

Astuce Scenari : si vous utilisez ScenarichainDesktop ou bien toute autre application Scenari individuellement sur votre propre poste, il est possible de manipuler deux fenêtres application du même atelier.

Il suffit de cliquer sur le menu de trois petits points verticaux en haut à gauche de la fenêtre, puis d’aller dans le sous-menu Fenêtres > Dupliquer la fenêtre. Il existe un raccourci clavier : ctrl+n sur Windows/Linux, pomme+n sur Mac.

Cloonix est un outil d’aide à la construction de réseau virtuel. Il est basé sur Open vSwitch pour l’émulation du réseau constitué de switchs et LANs virtuels, sur crun et les namespaces pour la gestion de conteneurs et sur KVM pour ce qui concerne l’émulation des machines complètes.
Cloonix peut être considéré comme un hyperviseur qui permet de lancer des scénarios de démonstration impliquant des réseaux connectant de nombreuses machines virtuelles ou conteneurs. Ce logiciel open source permet d’automatiser et de rejouer des scénarios complets.

FRR est le logiciel open source qui permet de transformer une machine Linux en l’équivalent d’un routeur professionnel, ce logiciel implémente tous les protocoles de routage classique.

Podman est exactement comme Docker, un gestionnaire de conteneur.

Le but de cette dépêche est de présenter une démonstration qui tourne dans un podman et qui met en œuvre un réseau d’une soixantaine de conteneurs et qui peut être lancé en tant qu’utilisateur simple sans les droits root.

Il y a le lien « demo » qui montre une vidéo un peu accélérée de cette démonstration qui démarre les machines, les configure et les met en réseau. On peut ensuite y voir la convergence du protocole OSPF.

Il y a quelques années, je vous avais présenté TuxMake, un utilitaire pour faciliter la (cross-)compilation du noyau Linux supportant une grande variété de toolchains différentes : TuxMake et le noyau Linux.

TuxMake facilitant la compilation du noyau Linux, nous nous sommes alors attaqués à rendre l’exécution de ces noyaux plus aisée : ainsi est né TuxRun.

Exemples

TuxRun propose une interface en ligne de commande simple pour exécuter un noyau dans QEMU. TuxRun se charge de fournir un environnement suffisant pour démarrer le noyau avec QEMU.

tuxrun --device qemu-arm64 \
       --kernel https://example.com/arm64/Image

TuxRun va alors télécharger le noyau et un système de fichier compatible avec ARM64 puis lancer qemu-system-arm64 avec les bons arguments et afficher les logs du boot.

La ligne de commande de qemu générée par TuxRun est la suivante :

/usr/bin/qemu-system-aarch64 \
    -cpu max,pauth-impdef=on \
    -machine virt,virtualization=on,gic-version=3,mte=on \
    -nographic -nic none -m 4G -monitor none -no-reboot -smp 2 \
    -kernel /.../Image \
    -append "console=ttyAMA0,115200 rootwait root=/dev/vda debug verbose console_msg_format=syslog systemd.log_level=warning earlycon" \
    -drive file=/.../rootfs.ext4,if=none,format=raw,id=hd0 \
    -device virtio-blk-device,drive=hd0

Il est également possible de lancer une suite de tests directement depuis la ligne de commande :

tuxrun --device qemu-arm64 \
       --kernel https://example.com/arm64/Image \
       --tests ltp-smoke

Les résultats de la suite de test seront analysés par TuxRun et la valeur de retour de TuxRun sera 0 uniquement si la suite de tests passe intégralement. Ceci permet d’utiliser TuxRun pour valider qu’une suite de tests donnée fonctionne toujours correctement sur un nouveau noyau.

Architectures

QEMU

Grâce à QEMU, TuxRun supporte de nombreuses architectures:
- ARM: v5/v7/v7be/64/64be
- Intel/AMD: i386/x86_64
- MIPS: 32/32el/64/64el
- PPC: 32/64/64le
- RISCV: 32/64
- sh4, sparc64, …

La liste complète est disponible dans la documentation.

FVP

Il est également possible d’utiliser FVP, le simulateur de ARM pour simuler un processeur ARMv9. FVP est un simulateur bien plus précis que QEMU au prix d’un temps d’exécution bien supérieur.

FVP permettant de configurer et simuler de nombreux composants du processeur, TuxRun propose une configuration permettant de démarrer et tester Linux dans un temps raisonnable.

tuxrun --device fvp-aemva \
       --kernel https://example.com/arm64/Image \
       --tests ltp-smoke \
       --image tuxrun:fvp

ARM ne permettant pas (pour le moment) de redistribuer les binaires FVP, il faut construire localement le container tuxrun:fvp.

Système de fichiers

Par défaut, TuxRun télécharge et utilise un système de fichier compatible avec l’architecture cible. TuxRun fournit donc 20 systèmes de fichiers différents, un pour chaque architecture disponible.

Ces systèmes de fichiers sont basés sur buildroot et comportent les outils nécessaires pour faire tourner la majorité des suites de tests supportés par TuxRun. La liste complète est disponible dans la documentation.

Il est également possible d’utiliser un autre système de fichiers :

tuxrun --device qemu-arm64 \
       --kernel https://example.com/Image \
       --rootfs https://example.com/rootfs.ext4.zst

Runtimes

TuxRun télécharge et utilise un container que nous maintenons. Ce container inclut l’ensemble des binaires nécessaires ainsi que QEMU. Par défaut, TuxRun utilise toujours la dernière version du container disponible.

Il est cependant possible de spécifier une version particulière afin de reproduire plus facilement une erreur. Les nouvelles versions de QEMU introduisent quelques fois des régressions dans les suites de tests. Il est alors nécessaire d’utiliser exactement la même image pour reproduire le problème.

Reproduire un test

TuxRun est utilisé, via tuxsuite notre service de compilation et de test dans le cloud, par le projet LKFT (Linux Kernel Functional Testing) de Linaro. Lorsqu’une régression est détectée, il suffit de fournir la ligne de commande TuxRun pointant sur les artefacts utilisés pour pouvoir reproduire le problème.

Les développeurs du noyau sont alors à même de reproduire et de corriger les régressions détectées par LKFT. TuxRun simplifie ainsi énormément la reproduction du test.

Un exemple parmi tant d’autres : selftests: sigaltstack: sas…

Installation

TuxRun étant un programme Python, il est possible de l’installer depuis pypi :

python3 -m pip install tuxrun

Nous fournissons également un paquet Debian, et un rpm.

TuxMake et Tuxrun

Dans un prochain article, je vous montrerai comment combiner TuxMake et TuxRun pour automatiquement trouver le commit responsable de la régression dans le noyau.

En ce mardi 26 mars, la communauté du Projet Fedora sera ravie d'apprendre la disponibilité de la version Beta de Fedora Linux 40.

Malgré les risques concernant la stabilité d’une version Beta, il est important de la tester ! En rapportant les bogues maintenant, vous découvrirez les nouveautés avant tout le monde, tout en améliorant la qualité de Fedora Linux 40 et réduisant du même coup le risque de retard. Les versions en développement manquent de testeurs et de retours pour mener à bien leurs buts.

La version finale est pour le moment fixée pour le 16 ou 23 avril.

Sommaire

• Expérience utilisateur
• Gestion du matériel
• Internationalisation
• Administration système
• Développement
• Projet Fedora
• Tester

Expérience utilisateur

• Passage à GNOME 46 ;
• L'environnement de bureau KDE Plasma change de version majeure avec sa nouvelle version 6 ;
• Le fichier firefox.desktop est renommé en org.mozilla.firefox.desktop pour permettre son utilisation dans la barre de recherche de GNOME.

Gestion du matériel

• Fourniture de ROCm 6 pour améliorer la prise en charge de l'IA et le calcul haute performance pour les cartes graphiques AMD ;
• Passage à l'étape 2 de la prise en charge du noyau unifié nommée UKI (donc unifiant noyau, initrd, ligne de commande du noyau et signature) pour les plateformes avec UEFI mais rien ne change par défaut à ce sujet.

Internationalisation

• Le gestionnaire d'entrée de saisie IBus passe à la version 1.5.30 ;
• Mise à jour de ibus-anthy 1.5.16 pour la saisie du japonais.

Administration système

• NetworkManager tente de détecter par défaut les conflits d'usage d'adresse IPv4 avec le protocole Address Conflict Detection avant de l'attribuer à la machine ;
• NetworkManager va utiliser une adresse MAC aléatoire par défaut pour chaque réseau Wifi différent, et cette adresse sera stable pour un réseau donné. Cela permet de concilier vie privée et confort d'utilisation ;
• Les unités système de systemd vont utiliser par défaut beaucoup d'options pour améliorer la sécurité des services ;
• Les entrées des politiques SELinux qui font référence au répertoire /var/run font maintenant référence au répertoire /run ;
• L'outil SSSD ne prend plus en charge les fichiers permettant de gérer les utilisateurs locaux ;
• DNF ne téléchargera plus par défaut la liste des fichiers fournie par les différents paquets ;
• L'outil fwupd pour mettre à jour les firmwares va utiliser passim comme cache pour partager sur le réseau local les métadonnées liées aux mises à jour disponibles pour les firmwares ;
• Les systèmes Fedora Silverblue et Kinoite disposent de bootupd pour la mise à jour du chargeur de démarrage ;
• Le paquet libuser est marqué en voie de suppression pour Fedora 41 alors que le paquet passwd est supprimé ;
• Le paquet cyrus-sasl-ntlm a été supprimé ;
• La gestion des droits utilisateurs pam_userdb passe de la base de données BerkeleyDB à GDBM ;
• Le filtre antispam bogofilter utilise SQLite au lieu de BerkeleyDB pour gérer sa base de données interne ;
• Le serveur LDAP 389 passe de la version 2.4.4 à la version 3.0.0 ;
• Le paquet iotop est remplacé par iotop-c ;
• L'orchestrateur de conteneurs Kubernetes évolue de la version 1.28 à la version 1.29 ;
• Par ailleurs ses paquets sont restructurés ;
• Pendant que podman est mis à jour vers la version 5 ;
• Le paquet wget2 remplace le paquet wget en fournissant une nouvelle version ;
• Le gestionnaire de base de données PostgreSQL migre vers sa 16e version ;
• Les paquets MySQL et MariaDB sont remaniés et mis à jour vers la version 10.11.

Développement

• Mise à jour de la suite de compilation GNU : GCC 14.0, binutils 2.41, glibc 2.39 et gdb 14.1 ;
• La suite de compilateurs LLVM est mise à jour à la version 18 ;
• Mise à jour de la bibliothèque C++ Boost à la version 1.83 ;
• Le langage Go passe à la version 1.22 ;
• Le JDK de référence pour Java passe de la version 17 à 21 ;
• Mise à jour du langage Ruby 3.3 ;
• Le langage PHP utilise la version 8.3 ;
• La boîte à outils pour le machine learning PyTorch fait son entrée dans Fedora ;
• Le paquet python-sqlalchemy utilise la nouvelle branche majeure 2.x du projet, le paquet python-sqlalchemy1.4 est proposé pour garder la compatibilité ;
• La bibliothèque de validation des données Pydantic utilise dorénavant la version 2 ;
• La bibliothèque Thread Building Blocks passe du fil 2020.3 au fil 2021.8 ;
• La bibliothèque OpenSSL 1.1 est supprimée ne laissant que la dernière version de la branche 3.x ;
• Les bibliothèques zlib et minizip utilisent leur variante zlib-ng et minizip-ng dorénavant ;
• Le langage Python ne bénéficie plus de la version 3.7.

Projet Fedora

• L'édition Cloud sera construite avec l'utilitaire Kiwi dans Koji ;
• Tandis que l'édition Workstation aura son ISO générée avec l'outil Image Builder ;
• L'image minimale ARM sera construite avec l'outil OSBuild ;
• Fedora IoT bénéficiera d'images Bootable Containers ;
• Il bénéficiera également des images Simplified Provisioning ;
• Et le tout sera construit en utilisant rpm-ostree unified core ;
• Fedora sera construit avec DNF 5 en interne ;
• Les macros forge passent du paquet redhat-rpm-config à forge-srpm-macros ;
• La construction des paquets échouera si l'éditeur de lien détecte certaines classes de vulnérabilité dans le binaire en construction ;
• Phase 3 de l'usage généralisé des noms abrégés de licence provenant du projet SPDX pour la licence des paquets plutôt que des noms du projet Fedora ;
• Clap de fin pour la construction des mises à jour au format Delta RPM ;
• Suite du projet de ne générer les JDKs qu'une fois, et les rempaqueter ainsi à toutes les variantes du système ;
• Compilation des paquets en convertissant plus d'avertissements comme erreurs lors de la compilation des projets avec le langage C ;
• Les images immuables comme Silverblue seront nommées sous la dénomination Atomic pour éviter la référence au terme immuable qui est confus pour les utilisateurs.

Tester

Durant le développement d'une nouvelle version de Fedora Linux, comme cette version Beta, quasiment chaque semaine le projet propose des journées de tests. Le but est de tester pendant une journée une fonctionnalité précise comme le noyau, Fedora Silverblue, la mise à niveau, GNOME, l’internationalisation, etc. L'équipe d'assurance qualité élabore et propose une série de tests en général simples à exécuter. Il suffit de les suivre et indiquer si le résultat est celui attendu. Dans le cas contraire, un rapport de bogue devra être ouvert pour permettre l'élaboration d'un correctif.

C'est très simple à suivre et requiert souvent peu de temps (15 minutes à une heure maximum) si vous avez une Beta exploitable sous la main.

Les tests à effectuer et les rapports sont à faire via la page suivante. J'annonce régulièrement sur mon blog quand une journée de tests est planifiée.

Si l'aventure vous intéresse, les images sont disponibles par Torrent ou via le site officiel.

Si vous avez déjà Fedora Linux 39 ou 38 sur votre machine, vous pouvez faire une mise à niveau vers la Beta. Cela consiste en une grosse mise à jour, vos applications et données sont préservées.

Nous vous recommandons dans les deux cas de procéder à une sauvegarde de vos données au préalable.

En cas de bogue, n'oubliez pas de relire la documentation pour signaler les anomalies sur le BugZilla ou de contribuer à la traduction sur Weblate. N'oubliez pas de consulter les bogues déjà connus pour Fedora 40.

Bons tests à tous !

Suite à la dépêche Comparatif : GrapheneOS vs LineageOS, je souhaitais faire part d’un retour d’expérience sur l’utilisation de GrapheneOS sur un téléphone Android Pixel 7a. Ce commentaire est repris ici sous forme de dépêche.

Sommaire

• PixelOS
  • Installation
  • Interface
  • Fonctionnalités spécifiques/avancées de PixelOS
• GrapheneOS
  • Installation
  • Interface
  • Applications et « stores »
  • Gestion des autorisations
  • Séparation des usages
  • Détail des approches suivies
    • 1ʳᵉ approche
    • 2ᵉ approche (test en cours)
    • 3ᵉ approche (d’ici une semaine)
  • Détails : utilisation sans les services Google
    • Synchronisation des contacts & agendas
    • Quid des applications non libres hébergées sur le play store
  • Détails : Utilisation avec les services Google
    • Dans un profil séparé
    • Via la fonction « work profile » d’Android
• Conclusion, cas d’usages et « threat model » (modèle de menace)
  • Sécurité
  • Vie privée
  • Facilité d’utilisation
  • Note : l’impact du matériel (« hardware ») sur la vie privée

Le point de départ est celui d’un utilisateur sensible aux logiciels libres mais qui utilise un téléphone Android Samsung « comme tout le monde », avec :

• Utilisation du Google Play Store, avec un compte Google personnel
• Utilisation d’un compte Google professionnel
• Utilisation du Samsung store, avec un compte Samsung
• Utilisation d’une montre connectée Samsung avec appli Samsung health

L’utilisateur a déjà expérimenté par le passé les solutions suivantes :

• UbuntuOS (abandonné rapidement par manque d’applications)
• LineageOS, avec Micro-G + « signature spoofing » pour permettre l’installation des applications bancaires

PixelOS

Installation

La mise en œuvre du système « stock » installé sur le smartphone est très facile et simple d’utilisation. Les téléphones Pixel proposent des fonctionnalités « avancées » spécifiques qui sont proposées au démarrage, avec à chaque fois le jeu de « voulez-vous activer cette fonctionnalité ? Si oui, acceptez le contrôle des données suivantes… »
On est dans un environnement full google, donc avec quelques habitudes à changer me concernant venant d’un environnement Samsung (la surcouche de l’OS est différente).

Interface

Launcher Pixel avec une barre de recherche Google qui ne peut pas être enlevée (The search bar cannot be removed from the bottom of the home screen, it's part of the Pixel Launcher https://support.google.com/pixelphone/thread/133065648/is-there-any-way-to-remove-the-google-search-bar-from-the-home-screen?hl=en), sinon tout est fluide / "beau"

Fonctionnalités spécifiques/avancées de PixelOS

• Déblocage du téléphone par reconnaissance faciale (probablement un cauchemar en termes de privacy, mais je pourrais comprendre pourquoi une personne lambda souhaiterait activer ce service)
• « Double tap » au dos du téléphone pour lancer une action (dans mon cas : la lampe torche)
  • On peut utiliser Torchie pour une fonctionnalité proche (https://f-droid.org/fr/packages/in.blogspot.anselmbros.torchie/)
  • Les fonctions d’urgence « avancées » fournies par l’application « sécurité personnelle » (https://play.google.com/store/apps/details?id=com.google.android.apps.safetyhub&hl=fr&gl=US)
  • L’application est disponible sur le playstore mais ne fonctionne pas sur GrapheneOS
  • Il existe une fonction d’urgence « de base » dans GrapheneOS (AOSP ?) (appuyer 5x sur power pour lancer un appel d’urgence vers le 112)
  • Dans PixelOS, il y a un conflit de raccourcis entre « appuyer 5x sur power pour lancer un appel d’urgence » et l’option « appuyer 2x pour lancer l’appareil photo » (quand les deux sont activées : l’appareil photo prend le dessus)
• Paiements NFC (non accessibles sur GrapheneOS)
  • Certaines applications de paiement autres que Google Wallet peuvent fonctionner (par ex. Paylib)
• Fonctionnalité « bien être numérique », notamment le fait de passer l’écran en noir & blanc à partir d’une certaine heure pour tenter de limiter le temps devant les écrans. L’application existe dans le Play Store (https://play.google.com/store/apps/details?id=com.google.android.apps.wellbeing&hl=fr&gl=US) mais impossible à retrouver depuis le client Play Store sur le téléphone.
  • Il existe probablement des alternatives

GrapheneOS

Installation

Procédure d’installation web très simple et rassurante. C’est la première fois que je me verrai recommander ce type d’install à un utilisateur non technique (alors que la procédure d’install de LineageOS - à l’époque ou j’ai essayé - est complexe et obscure, avec le risque de se planter à plusieurs étapes).

Interface

• Le bureau par défaut est très minimaliste et pas très accueillant (je sais que cela peut paraître peu important, mais le fond noir + icônes en noir & blanc peut rebuter / n’est pas aussi accueillant que le système de base).
  • Possibilité d’utiliser un launcher alternatif : j’ai fini sur Lawnchair après en avoir testé plusieurs
  • Possibilité de changer le fond d’écran : Muzei (https://f-droid.org/fr/packages/net.nurik.roman.muzei/) / Walman (https://apt.izzysoft.de/fdroid/index/apk/com.colorata.wallman)
• Le clavier par défaut m’a dérangé (après des années à utiliser le clavier Gboard), surtout pour l’écriture « swipe » (que je pratique souvent quand j’écris un message à une main).
  • Possibilité d’utiliser un clavier alternatif : Home:FlorisBoard (https://f-droid.org/fr/packages/dev.patrickgold.florisboard/) est pas mal, il inclut une fonction « swipe » mais qui n’est pas aussi précise

Applications et « stores »

• Le « store » par défaut « Apps » contient le minimum vital.
  • Pour le compléter, je suis passé par l’application Droid-Ify (https://droidify.eu.org/ ou https://github.com/Droid-ify/client) dans lequel j’ai activé les dépôts F-droid et Home:IzzyOnDroid

Pour le Store Google, il est possible d’installer plusieurs « briques » de l’éco-système :

• Google Services Framework (GSF), dont dépendent :
  • Google Play services + Google Play Store (interdépendants) On peut donc choisir : rien du tout, GSF pour les applis qui en dépendent, ou les trois.

Gestion des autorisations

• Les possibilités sont très fournies = positif (permet de limiter les accès réseau, les accès stockage)
• Les possibilités sont très fournies = complexe à gérer : il faut se poser des questions / passer du temps à configurer les choses.
  • Exemple : la synchronisation des contacts Google ne se fait pas sans la permission « Contacts » dans l’appli « Google Services Framework ».

Séparation des usages

Il existe deux approches possibles de séparation des usages :

• Utilisation d’un « user profile » : il s’agit d’un profil complètement distinct. On peut passer de l’un à l’autre assez facilement. Les deux profils ne peuvent pas se parler, sauf via les notifications croisées (https://www.youtube.com/watch?v=WjrANjvrSzw)
• Utilisation d’un « work profile » : ici on utilise un seul profil, mais à l’intérieur duquel on vient activer la fonctionnalité « work profile » d’Android pour séparer les usages (via une application tierce telle que Shelter, https://www.youtube.com/watch?v=20C0FD7mGDY pour une explication détaillée)

Détail des approches suivies

1ʳᵉ approche

• Profil « owner » avec Shelter
  • Profil « Personnel » = pas de services Google
  • Profil « Professionnel » = Services Google avec compte personnel
• 2ᵉ Profil « Travail » = Services Google avec compte professionnel

Ce qui bloque : je voulais utiliser la fonctionnalité « work profile » d’Android avec Shelter pour isoler mon compte Google personnel. Hors c’est ce compte qui jusqu’ici synchronise les contacts. Les applications par défaut de GrapheneOS ne gèrent pas cette synchro (autrement que via import/export manuel, ou alors je n’ai pas trouvé comment). Si on veut quelque chose qui s’intègre tout seul il faut passer par les applications Google de Téléphone/Contacts/Calendrier. Hors ces applications ne peuvent pas devenir « applications par défaut » (pour remplacer celles existantes de GrapheneOS) dans le « work profile », c’est le profil personnel qui gère cette configuration.

2ᵉ approche (test en cours)

• Profil « owner » (unique, sans Shelter) = Services Google avec compte personnel
• 2ᵉ Profil « Travail » (unique, sans Shelter) = Services Google avec compte professionnel

Ce qui bloque : j’utilise le téléphone à la fois pour le pro & perso, sauf que le fait d’avoir deux profils implique de jongler systématiquement entre les deux profils. Trop compliqué au quotidien.

3ᵉ approche (d’ici une semaine)

• Profil « owner » avec Shelter
  • Profil « standard » = Services Google avec compte personnel
  • Profil « work » = Services Google avec compte personnel

Détails : utilisation sans les services Google

Synchronisation des contacts & agendas

La première problématique c’est la synchro des contacts et des agendas. Pour se passer de Google sur ce point, il faut mettre en place au préalable un service de partage de contact / agenda :

• Nextcloud + DAVx⁵
• https://www.etesync.com/
• https://www.chatons.org/
• NAS Synology + leurs applications (mais uniquement accessibles sur Google Play Store…)

Bref c’est un projet en tant que tel, pas forcément à la portée de tous

Quid des applications non libres hébergées sur le play store

À ce stade, pour accéder à d’éventuelles applications uniquement présentes sur le Play Store, il est possible de :

• passer par l’application Aurora
• passer par apkmirror pour les télécharger une à une

Cependant, de nombreuses applications du Play Store requièrent l’installation du Google Services Framework (« GSF ») pour fonctionner.

Me concernant, j’ai la liste suivante d’applications que j’ai pu récupérer par ce biais (et qui fonctionnent sans GSF) :

• Appli Banque (SG)
• Paiement NFC via Paylib (pas encore testé « en vrai » mais l’appli s’installe sans broncher)
• Deezer (musique)
• Somfy (alarme)
• NetAtmo (thermostat connecté)
• Doctolib (Santé)
• Appli mutuelle (Alan)
• Freebox connect (utilitaire freebox)
• Wifiman (utilitaire réseau)

Certaines applications nécessitent le GSF, c’est le cas notamment de :

• Whatsapp (pour les notifications « push » et pour transfèrer l’historique des messages)
  • Il semble que des transferts « locaux » soient possibles
    • https://faq.whatsapp.com/6181521285295518/?helpref=hc_fnav&cms_platform=android
    • https://faq.whatsapp.com/209942271778103/?helpref=hc_fnav&cms_platform=android
• Bose connect (gestion casque bluetooth Bose qui indique l’erreur « Services Google Play manquants »)
  • Le casque peut fonctionner en bluetooth sans l’application

Détails : Utilisation avec les services Google

Dans un profil séparé

J’ai mis du temps à comprendre / trouver comment activer la fonctionnalité de profils multiples (alors que c’est simple) : Paramètres > Système > Utilisateurs multiples > Autoriser plusieurs utilisateurs (https://www.youtube.com/watch?v=SZ0PKtiXTSs)

Le profil séparé à l’avantage d’être comme un « deuxième téléphone ». C’est aussi un inconvénient pour les personnes qui ne sont pas prêtes à faire cet « effort » (passer de l’un à l’autre), même si les notifications « cross profile » aident sur ce point.
Il faut reproduire sur chacun des profils toutes les « custo » faites (changement de launcher, de clavier, configurations diverses, etc).

Via la fonction « work profile » d’Android

La fonction work profile fournit une séparation moins forte, mais c’est aussi plus « pratique » au quotidien car toutes les applications (et les comptes) sont dans un seul profil. J’ai testé via l’application Shelter.

Avantages :

• Tout est accessible dans le même profil
• Dans le tiroir d’application, on retrouve deux « onglets » séparant les applications « perso » et « pro ».

Inconvénients :

• Comme pour le profil séparé, il y a une « double maintenance »
  • Ex: en cas d’utilisation de deux profils Google Play (profil perso + pro), il faut faire les mises à jour « des deux côtés »
• Il faut bien choisir dans quel contexte on souhaite installer chaque application
• Je n’ai pas trouvé comment faire pour 1. Synchroniser mon compte Google perso dans le « work profile » de Shelter et 2. faire remonter ces informations dans les applications « contacts » et « téléphone » par défaut de GrapheneOS. C’est le profil « Personnel » qui va dicter quelles applications par défaut sont utilisées.

Conclusion, cas d’usages et « threat model » (modèle de menace)

J’ai passé beaucoup plus de temps que prévu à comprendre GrapheneOS, tester différentes solutions et configurer les options / trouver des alternatives. Je suis bien conscient que plusieurs « problèmes » remontés pourraient tout simplement être résolus si j’acceptais de faire les choses différemment. Cela me pousse à m’interroger sur le compromis à choisir entre sécurité / respect de la vie privée / facilité d’utilisation ? Cette question dépend bien sur du modèle de menace (« threat model ») de chacun.

Sécurité

GrapheneOS répondrait parfaitement à des contraintes de sécurité « forte » pour des personnes étant journaliste / activiste / lanceur d’alerte / député. Dans ce cas d’usage, le coût de la sécurité est accepté.

Vie privée

GrapheneOS apporte un choix indéniable permettant à chacun de trouver le meilleur usage possible.

Facilité d’utilisation

Dans mon cas d’usage, je trouve que la fonction de profil séparé apporte trop de friction au quotidien, et je suis prêt à tout rassembler au sein du même profil. L’utilisation de deux téléphones différents (un perso / un pro) pourrait être une alternative. De la même manière, je n’ai pas encore passé le pas de me séparer de mon compte Google (pour la synchro des contacts / agendas), donc pour le moment je continue d’utiliser le Play Store. À terme, j’essaierai de ne plus en dépendre.

Note : l’impact du matériel (« hardware ») sur la vie privée

• Un casque Bluetooth Bose nécessite l’app « Bose Connect » qui dépend de GSF/Play Store
• Un casque Bluetooth Samsung Buds2 Pro nécessite l’app Samsung qui demande la création d’un compte cloud chez eux
• L’application Google Wallet me permet de régler mes courses via paiement NFC, mais donne accès par ce biais à un pan entier de données personnelles

À chaque fois la question est : est-ce utile ou pas ? Puis-je facilement m’en passer ?