volted.net

A blog about being free, as in free speech

Leap 15.2 c'est pour bientôt

23 juin, 2020 — sogal

Tags: opensuse

Mises à jour de GNOME, LLVM, Samba, Ruby dans Tumbleweed

01 décembre, 2019 — sogal

Deux instantanés openSUSE Tumbleweed ont été publiés cette semaine, mettant à jour plusieurs bibliothèques et une nouvelle version de GNOME, Ruby, Samba, Mozilla et le compilateur LLVM.

L'instantané 20191018 a fourni des mises à jour mineures pour Mozilla Firefox 69.0.3 et Thunderbird 68.1.2. La mise à jour de Firefox a corrigé un bug qui invitait les utilisateurs de Yahoo mail à télécharger des fichiers en cliquant sur les courriels et la mise à jour Thunderbird a corrigé quelques problèmes ainsi que l'importation de contacts dans le carnet d'adresses à partir d'un fichier CSV. La suite logicielle GNOME a été mise à jour vers la version 3.34, qui pourrait être la version qui entrera dans openSUSE Leap 15.2. Cette version de GNOME, nommée Thessaloniki, inclut des mises à jour visuelles pour un certain nombre d'applications et les paramètres de sélection d'arrière-plan ont également fait l'objet d'une refonte, ce qui facilite la sélection d'arrière-plans personnalisés. Les développeurs utilisant GNOME 3.34 remarqueront davantage de sources de données dans Sysprof facilitant le profilage des performances des applications. Les améliorations apportées à Builder incluent un inspecteur intégré D-Bus. Les liaisons Javascript pour GNOME ont également été mises à jour avec la version gjs 1.58.1 et la version gtk3 3.24.12 a corrigé un décalage de pointeur sous X11 et Wayland. L'environnement d'exécution Python2 a été supprimé avec la mise à jour de samba 4.11.0; python 3.4 ou une version ultérieure est désormais requise.

L'instantané 20191018 apportait une mise à jour du nouveau langage de programmation vala 0.46.3 qui se concentre sur les développeurs GNOME. Le langage de programmation ruby 2.6.5 a corrigé une vulnérabilité d'injection de code avec trois autres Vulnérabilités et expositions courantes. La paquet Snapper d'OpenSUSE 0.8.5 a été mis à jour pour permettre le suivi des commentaires dans les fichiers de configuration. Le noyau Linux a été mis à jour en 5.3.6. NetworkManager 1.18.4 a amélioré la gestion des règles de routage, des règles ajoutées en externe et des règles reprises après le redémarrage d'un service NetworkManager. Le package NetworkManager-applet 1.8.24 a ajouté la prise en charge de l'authentification SAE (WPA3 Personnel). Des correctifs de régression ont été apportés aux versions 2.62.1 de glib2 et de glib-networking; ce dernier a également inclus deux corrections de fuite mémoire. Les autres paquets remarquables mis à jour dans l'instantané étaient webkit2gtk3 2.26.1, libsoup 2.68.2, grilo 0.3.10 et dconf 0.34.0.

Selon le commentateur de clichés Tumbleweed, l’instantané a une cote stable de 92.

La plupart des mises à jour de l'instantané 20191016 concernaient des paquets YaST2. Un plantage causé par une méthode de widget a été corrigé dans yast2-network 4.2.23 et au moins 10 langues ont été mises à jour dans le package yast2-trans. Les personnes peuvent contribuer au projet en traduisant via l'instance openSUSE's Weblate. Il y avait une poignée d'autres paquets mis à jour dans l'instantané, mais le plus important à noter est une nouvelle version majeure de llvm9. La nouvelle version majeure du compilateur nécessite uniquement une base python3 au lieu des paquets python3 complets. L'optimiseur LLVM convertira désormais les appels à memcmp en appels à bcmp dans certaines circonstances. La version majeure ne considère plus non plus la cible RISCV comme "expérimentale". Il est maintenant construit par défaut, plutôt que d'avoir besoin d'être activé avec LLVM\ EXPERIMENTAL\ TARGETS_TO_BUILD.

Cet instantané a enregistré une note stable de 91, selon le commentateur de clichés Tumbleweed.

Updated via GHActions

Tags: opensuse

KDE et openSUSE: Plasma 5.17, Qt 5.14 plus encore

30 octobre, 2019 — sogal

Plasma 5.17 Beta

La version bêta de Plasma 5.17 a été publiée avec de nombreuses nouvelles fonctionnalités et améliorations telles que la mise à l'échelle fractionnelle par écran sur Wayland, une nouvelle interface utilisateur pour la configuration des autorisations des périphériques Thunderbolt et des statistiques réseau dans KSysGuard. Ce dernier nécessite plus de privilèges que d'habitude pour une application utilisateur. C'est pourquoi l'équipe de sécurité SUSE est en train de vérifier ces autorisations.

openQA a déjà trouvé quelques bogues, comme GIMP plus "en couleurs" que d'habitude et certaines applications telles que Kirigami et Qt Widgets qui casse certains raccourcis clavier. Les deux ont été corrigés dans l’intervalle et seront corrigés dans la version finale de 5.17.

Si vous n'avez pas encore testé Plasma 5.17 Beta, il reste encore un peu de temps! Si vous rencontrez un problème dans le logiciel, veuillez vous rendre sur KDE bug tracker. Si au lieu de cela vous trouvez un problème spécifique à openSUSE, rendez vous sur l'openSUSE bugzilla.

Pour obtenir Plasma 5.17 sur votre installation Leap ou Tumbleweed, vous pouvez lire https://fr.opensuse.org/SDB:KDE_repositories.

Si vous rencontrez des problèmes graves, l’instantané automatique du système de fichiers racine pris à l’aide de btrfs vous aide à revenir à l’état de fonctionnement en démarrant dans un instantané plus ancien et en faisant une restauration.

Argon, un support live installable comprenant Leap 15.1 avec la version bêta et ne nécessitant aucun ajout de dépôt manuel, est également disponible.

openSUSE Leap 15.2

Comme ce fut le cas pour Leap 42.2, 15.2 inclura également des mises à jour majeures de nombreux composants.

A côté d'une nouvelle version du noyau Linux, il est prévu de la livrer avec Qt 5.12 LTS, Plasma 5.18 (bien sûr également LTS) et les dernières versions de KDE Frameworks et Applications, que nous pourrons faire entrer suffisamment tôt pour que les tests appropriés garantissent la meilleure expérience utilisateur possible!

Cela signifie que la session "Full Wayland" qui a atterri dans Tumbleweed il y a quelques semaines sera également disponible dans Leap 15.2 de même que la prise en charge de la mise à l'échelle fractionnelle par écran.

Comme les versions cibles d'Applications, Frameworks et Plasma ne sont pas encore connues, nous intégrons actuellement Qt 5.12 LTS aux derniers packages de Factory.

Qt 5.14

Les utilisateurs de Tumbleweed et de Leap sont habitués à bénéficier des versions les plus récentes des logiciels KDE incluant les fonctionnalités et corrections de bogues disponibles, ce qui n'est possible qu'en suivant le développement de Qt et en agissant de manière proactive.

Ainsi, bien que la branche 5.1 de Qt soit encore jeune, nous sommes déjà en train de l'intégrer dans nos versions. Lors de la construction initiale de la version 5.14 Alpha, certains bogues (QTBUG-78867, QTBUG-78881, QTBUG-78911, QTBUG-78948) avaient déjà été identifiés et corrigés pour la plupart, de sorte que le projet KDE:Qt:5.14 est construit et utilisable dès maintenant. Pour développer avec Qt 5.14 et tester vos applications, vous n'avez plus qu'à ajouter le dépôt.

Jusqu'ici, nous en sommes toujours à la phase d'intégration et nous préparons tout ce qui doit l'être, mais nous soumettrons bientôt Qt 5.14 en zone de transit de Factory afin de voir comment il s'y intègre.

L'une des caractéristiques les plus visibles pour l'utilisateur est que la mise en œuvre de la mise à l'échelle (pour les écrans HiDPI) a été principalement réécrite. Parmi les autres changements notables, citons l'ajout de divers systèmes d’accélération de Qt Quick utilisant une nouvelle couche d’abstraction (opt-in), qui peut désormais tirer parti de Vulkan ainsi que l'introduction d'un nouveau module "qtquicktimeline", qui permet de faciliter intégration d'animations basées sur la chronologie dans Qt Quick.

Tags: opensuse

Les nouveaux Node.js LTS, débogueur GNU et libvirt débarquent dans les instantanés Tumbleweed

23 juin, 2019 — sogal

Les trois instantanés openSUSE Tumbleweed publiés cette semaine ont mis à jour certains paquets clés pour les utilisateurs de cette version en publication continue.

Un de ces paquets clés était une mise à jour du débogueur GNU, gdb 8.3, publié dans l'instantané 20190607. Le débogueur a activé les tests ada sur les plate-formes ppc64le et riscv64. Les versions multitarget pour riscv64 ont également été activées. L'instantané a également ajouté les tests unitaires pour Logical Volume Manager (LVM) sur disque modulaire (MD) avec la mise à jour de libstorage-ng 4.1.127. Plusieurs correctifs et corrections de bogues ont été appliqués avec la mise à jour de libvirt 5.4.0, ce qui a également permis d'améliorer les liens statiques inutiles, qui entraînait à la fois l'encombrement du disque et de la mémoire. Libvirt a également introduit le support du bit md-clear CPUID. Le package python-libvirt-python 5.4.0 a ajouté la nouvelle interface de programmation (API) et des constantes dans libvirt 5.4.0. L’éditeur de texte vim 8.1.1467 présentait de multiples correctifs, mais l’instantané Tumbleweed a introduit de nouveaux bogues et affiche actuellement une cote de 86, selon le commentateur d’instantané.

Les deux instantanés précédents ont enregistré une note exceptionnelle exceptionnelle de 98 selon le relecteur d’instantané (http://review.tumbleweed.boombatower.com/).

L'instantané 20190606 n'a mis à jour que deux paquets. Le paquet nodejs10 a mis en place une nouvelle version amont à support à long terme (LTS) avec nodejs10 10.16.0 et une mise à jour des sources d'openssl et libuv en version 1.28.0. L'autre mise à jour importante du paquet dans l'instantané était xfdesktop en 4.12.5; ce package pour Xfce 4 a corrigé la taille des icônes dans les paramètres, réinitialisé l'ordre des icônes du bureau et corrigé une [fuite de timer](https://bugzilla.xfce.org /show_bug.cgi?id=13887).

L'instantané 20190605 comportait trois packages mis à jour. Le noyau Linux 5.1.7 avait quelques corrections concernant Btrfs telles que la correction de l'état interne avec un périphérique de stockage situé entre fsync et l'écriture différée des plages adjacentes. La mise à jour du noyau a également supprimé les dépendances avec les éléments internes du pilote arch_timer pour l'architecture arm et ajouté la prise en charge d'Ice Lake au sein de la gestion d'alimentation [x86] d'Intel. Les fuseaux horaires ont été mis à jour avec le package libical 3.0.5 et le package libinput 1.13.2 a apporté des modifications à la prise en charge des pavés tactiles Wacom et Apple Bluetooth.

Le responsable des publications, Dominique Leuenberger, a rédigé un compte rendu des deux semaines précédentes et a déclaré qu'openssl 1.1.1c, Texlive 2019, KDE Plasma 5.16, Qt 5.13, LLVM 8, swig 4.0 et cmake 3.14 progressaient tous dans la file d'attente et seraient bientôt disponibles dans les prochains instantanés de Tumbleweed.

Tags: opensuse

Mise à jour des packages Mesa, VirtualBox, Ceph et NetworkManager dans Tumbleweed

11 juin, 2019 — sogal

Trois instantanés openSUSE Tumbleweed ont été publiés au cours des quatre premiers jours de juin, ce qui entraîne plusieurs mises à jour des paquets dans cette rolling-release.

L'instantané 20190604 apportait le paquet babl 0.1.64, améliorant la cohérence du code, la prise en charge de l'intégration continue (CI) de [gitlab](https://gitlab. com), ainsi que des améliorations d’autotools et meson build. Un accident dans la dénomination a entraîné le passage de la version 0.3.2 de bubblewrap à la version 0.3.3. Cependant, bubblewrap 0.3.3. a corrigé une vulnérabilité (CVE), fourni quelques corrections plus petites et ajouté l’API (Application Programming Interface) JSON qui permet de lire le code de sortie du processus interne. GNU Compiler Collection 8 a eu quelques mises à jour qui comprenaient quelques correctifs dont un rendant les constructions sans profilage reproductibles. La bibliothèque Generic Graphics Library gegl 0.4.16 a également ajouté le support de gitlab CI et utilise un allocateur personnalisé pour les données de mosaïque, qui aligne les données et les allocations de groupes dans des blocs ; ceci a été réalisé sur Linux en utilisant l'extension GNU malloc_trim pour permettre de forcer l'invocation de la fonction de récupération de place d'allocateurs, malloc, présente au sein de la glibc. La version 6.0.8 d’Oracle virtualbox corrigeait un crash lors de la mise hors tension d’une machine virtuelle sans contrôleur graphique et la version 1.20.5 de xorg-x11-server en corrigeait certains types d'entrées. L’instantané a actuellement une cote de 96, selon l'évaluateur d’instantané.

L'instantané 20190603 a mis à jour Mesa et Mesa-drivers en version 19.0.5 améliorant certaines parties du code et des pilotes. NetworkManager 1.16.2 a corrigé certaines autorisations erronées du fichier /var/lib/NetworkManager/secret_key. La mise à jour de la version mineure de Ceph a désactivé l'[Optimisation du temps de liaison](https://stackoverflow.com/questions/23736507/is-there-a-rreason-why-not-to -use-link-time-optimization-lto) dans le fichier spec lors de son utilisation. GNOME 3.32.2 comportait plusieurs mises à jour et correctifs de packages, notamment le correctif d'une régression qui entraînait la disparition de la catégorie "Fonts" (Polices). Tumbleweed a zappé la série 1.3.0 de Flatpak pour fournir directement à la version 1.4.0. Les principales modifications depuis la version 1.2.4 concernent l'utilisation améliorée des Entrées/Sorties pour les applications installées sur le système et le nouveau format des dépôts préconfigurées. Glib2 2.60.3 a mis à jour les traductions et fourni diverses corrections au support des petites clés/valeurs dans [GHashTable](https://developer.gnome.org/glib/stable /glib-Hash-Tables.html). Le langage de script php7 7.3.6 a ajouté une curl_version manquante et corrigé plusieurs autres bugs. L’instantané a actuellement une côte de 95, selon l'analyseur d’instantané (http://review.tumbleweed.boombatower.com/).

L'instantané qui a commencé le mois, 20190601, a mis à jour le [Noyau Linux](https: //www.kernel. org /) en version 5.1.5, ce qui corrigeait un bogue de perte de données. Flatpak-builder 1.0.7 a corrigé quelques détails sur la façon de créer des validations de plate-forme afin de résoudre les problèmes liés à la mise en cache de polices. La visionneuse d'images de GNOME gthumb 3.8.0 faisait partie des autres mises à jour de paquet contenues dans l'instantané en compagnie de ibus-libpinyin 1.11.1, libopenmpt 0.4.5, qalculate 3.2. 0, rdesktop 1.8.6, qui corrigeait le code du protocole gérant les nouvelles licences, et yast2-support 4.1.1. L’instantané a actuellement une cote de 90, selon l'analyseur d’instantané (http://review.tumbleweed.boombatower.com/).

Tags: opensuse

Compte-rendu de la conférence openSUSE 2019 (oSC19)

28 mai, 2019 — sogal

Du vendredi 24 au dimanche 26 s'est tenue, à Nuremberg, la conférence annuelle du projet openSUSE. Comme chaque année, cette conférence est l'occasion de rassembler les membres de la communauté, de présenter les projets en cours et les grandes tendances techniques, de boire des bières et de faire le point sur l'avenir du projet.

Logo oSC19

La conférence s'est ouverte le vendredi matin, par une keynote de Thomas DiGiacomo puis les présentations se sont enchaînées, avec pour thème principal de cette édition, les projets Kubic et MicroOS, c'est-à-dire plutôt des technologies évoluant autour de la containerisation applicative. En milieu de matinée, l'équipe d'EOS nous a présenté ses travaux autour de la création d'EOS Design System, un outil de création de design et d'interfaces cohérentes entre plusieurs sites web et applications. J'ai assisté ensuite à une présentation de Neal Gompa, membre actif des projets openSUSE et Fedora (par ailleurs sponsor de l'événement), qui a fait un comparatif des gestionnaires de paquets utilisés au sein des deux distributions. Après le repas, j'ai assisté à trois présentations autour des containers:

  • leur création avec openSUSE (en tant qu'hôte et système « invité ») ;
  • MicroOS, un projet openSUSE, qui vise à fournir un système d'exploitation minimal, mono objectif et tirant le meilleur parti des mises à jour atomiques ;
  • le déploiement d'un cluster Kubernetes.

Après le repas, offert par openSUSE et les sponsors de l'événement s'il vous plaît! et une bonne bière au soleil, j'ai poursuivi avec une présentation d'Ish Sookun détaillant comment exécuter des containers, en production, grâce à MicroOS puis avec une seconde présentant le déploiement de Ceph (un système de stockage distribué/répliqué) grâce à Rook, au sein d'un cluster Kubernetes sur une base Kubic.

En fin d'après midi, j'ai pris un peu le soleil en participant à la petite « chasse au trésor » dont l'objectif était de trouver une dizaine de QR codes puis de répondre aux questions sur openSUSE vers lesquelles ils pointaient. Un jeu fort sympa qui m'a permis de gagner une casquette openSUSE ! \m/(^_^)\m/

Photo casquette & beer

La journée s'est finie autour d'un pinte et d'un bon repas avec des personnes de chez SUSE et ARM, dans un chouette restaurant de la vieille ville (@ARM: merci pour tout le poisson).

Photo restaurant

Le samedi matin, j'étais bénévole pour aider à l'accueil, sous la houllette de Katrin aka Booth Babe, sainte-patronne des volontaires sur l'événement. En effet, il était demandé, dans la mesure du possible, aux membres bénéficiant du Travel Support Program, de filer un coup de main, ce qui est normal. Même si j'ai raté 2 conférences qui m'intéressaient (dont celle de Guillaume Gardet sur l'état d'openSUSE sur ARM, désolé Guillaume), j'ai fait la connaissance de Dimitar, un membre de la communauté openSUSE à Sofia, Bulgarie, très actif chez lui et pour le moins passionné puisqu'il a conduit près de 15h pour se rendre à Nuremberg !

Un peu avant midi, je suis allé voir une présentation sur les mises à jour transactionnelles. C'est un bien gros mot qui désigne un système de mises à jour dites « atomiques », à savoir qu'elles s'appliquent complètement ou pas du tout (ex.: une partie d'un paquet mais pas l'autre suite à un problème ou encore un paquet maître mais pas ses dépendances suite à une coupure réseau, etc.). openSUSE utilise les fonctionnalités d'instantanés (snapshots) de btrfs pour créer un instantané sur lequel les modifications induites par la mise à jour sont appliquées, laissant le système actuel dans son état fonctionnel. Ce snapshot sera appliqué au démarrage suivant. En cas de problème (impossibilité de booter, services non opérationnels), un roll-back est possible très facilement.

Par la suite, pingou, membre du projet Fedora, a présenté Pagure, une forge logicielle, basée sur Git, simple, puissante et efficace qu'il a rendu disponible dans openSUSE.

En fin d'après-midi, nous avons eu droit aux obligatoires lighting (beer (and wine)) talks. Si vous n'êtes pas familier du concept, il s'agît de très courtes présentations, 5 min, sur toutes sortes de sujets, durant lesquelles le présentateur doit toujours avoir une bière ou un verre de vin à la main. Le tout en expliquant son sujet, buvant, déroulant les diapositives et en tenant le micro. Tout un art !

Après la traditionnelle photo de groupe, nous avons eu droit au barbecue, sous un peu de pluie mais on va pas se plaindre suivi d'un petit concert super sympa donné par le SUSE Band allemand.

Photo concert

Le dimanche fut plus calme marqué surtout par deux conférences très intéressantes :

  • la présentation sur l'identité visuelle et les logos du projet openSUSE, par Stasiek Michalski (aka lcp). Il a présenté ses réflexions autour des éléments graphiques du projet, ce qui va et ne va pas et à fait de chouettes propositions qu'on peut retrouver sur Github ;
  • la seconde n'est rien d'autre que la traditionnelle discussion avec le conseil (board) openSUSE. Durant celle-ci, les membres du conseil nous ont présenté leur réflexion autour de leurs travaux sur la création d'une fondation openSUSE. Ceci n'est qu'au stade d'étude pour l'instant et sera soumis au vote (en 2 étapes) de la communauté mais présente a priori de nombreux avantages (moins de dépendance vis-à-vis de SUSE, possibilité d'avoir plus de sponsors, des dons matériels, des fonds collectés, etc...). Affaire à suivre de près donc.

Après une dernière petite bière sur place avec l'ami Guillaume, j'ai pris le large direction l'aéroport pour... une dernière petite bière à Nuremberg !

Dernière bière... et bretzel

Les conférences annuelles du projet sont vraiment un excellent moment, très intéressant tant techniquement qu'humainement et j'ai hâte de l'an prochain !

Tags: opensuse

Tumbleweed: nouvelles de la semaine 17

28 avril, 2019 — sogal

Quatre instantanés openSUSE Tumbleweed ont été publiés cette semaine. Ils fournissent un noyau Linux, des versions du framework KDE ainsi que python-setuptools pour offrir aux développeurs un grand nombre de nouveaux paquets upstream.

L'instantané Tumbleweed 20190423, le plus récent, fournissait un nouveau cups-filters 1.22.5 qui modifiait un appel Ghostscript afin de corriger le nombre de pages pour qu'il fonctionne avec Ghostscript 9.27 et les versions ultérieures. Le package de décodeur AV1 dav1d 0.2.2 apporte une augmentation de vitesse de 4 à 6% pour le décodage MSAC (Multi Slot Amplitude Coding) avec SSE. Le progiciel du noyau a été mis à jour en 20190409 et a mis à jour le fichier du micrologiciel pour les firmwares Intel Bluetooth et Marvell. Des traductions indonésiennes ont été faites dans le paquet libstorage-ng 4.1.112. Ruby 2.6.3 a mis à jour la version Unicode vers la version 12.1 bêta pour ajouter la prise en charge de New Japanese Era “令 和” (Reiwa). Les autres packages mis à jour dans l'instantané étaient perl-DateTime 1.51, perl-DateTime-TimeZone 2.35, python-parso 0.4.0, python-qt5 5.12.1 et rdma-core 23.0. Selon l'outil d'évaluation de Tumbleweed, cet instantané a actuellement une cote de 89.

Mesa 19.0.2 présentait quelques correctifs pour radeon, radv et v3d dans l'instantané 20190420. Quelques autres paquets ont été mis à jour dans cet instantané, tels que kipi-plugins 5.9.1, qui était la première version autonome en dehors de digikam. Selon l'évaluateur Tumbleweed, cet instantané affiche actuellement une côte de 97.

Les contributeurs de KDE ont proposé de nombreuses corrections et bibliothèques d'addons à Qt avec la mise à jour de Frameworks 5.57.0 dans l'instantané 20190419. Le framework d'interface utilisateur légère de KDE pour les applications mobiles et convergentes, appelée Kirigami, comportait la plupart des mises à jour, ainsi que KIO et les fonctions de gestion de fichiers qu'elle fournit aux utilisateurs de Konqi. Python-setuptools 41.0.0 est un autre package destiné aux développeurs qui est arrivé dans l'instantané. Le package supprime la prise en charge de la spécification d’un codage à l’aide d’une directive «coding:» dans l’en-tête du fichier. Lors de l'analyse des fichiers setup.cfg, setuptools exige désormais que les fichiers soient encodés en UTF-8. Java-11-openjdk mis à jour en 11.0.3.0 a ajouté des scénarios de test pour une analyse syntaxique japonaise et a implémenté plusieurs correctifs de sécurité. Cet instantané affichait une note stable de 97.

L'instantané qui a commencé la semaine, 20190418, affichait une note stable de 94. L'instantané a mis à jour ImageMagick vers la version 7.0.8.40 et résolvait plusieurs problèmes suivis sur github. Le paquet emacs 26.2 est maintenant compatible avec la dernière version 11.0 du standard Unicode et des modifications ont été apportées aux modes et paquets spécialisés dans Emacs 26.2 Dired: la commande ‘Z’ d’un nom de répertoire compresse désormais l’ensemble de ses fichiers. Le noyau Linux 5.0.8 comportait des correctifs pour les plate-formes arm et autres. Une des mises à jour du noyau a corrigé les régulateurs du codec audio du processeur AM335x Evaluation Module. Les autres packages mis à jour dans l'instantané étaient hwdata 0.322, sshfs 3.5.2 et yast2 4.2.0, nécessaires pour charger des frameworks de tests d'intégration.

Tags: opensuse

S'investir dans un projet Libre: ma candidature au Conseil openSUSE

06 janvier, 2019 — sogal

J'ai décidé ce jour de présenter ma candidature aux éléctions au Conseil openSUSE. Voici pourquoi.

Je ne suis pas un super hacker très expérimenté, je serais plutôt un bidouilleur très intéressé, toujours en apprentissage et aimant partager autour de savoir-faire techniques.

Depuis que je suis passé à openSUSE (voir ici), j'ai pris plaisir à créer et maintenir des paquets, dont certains sont maintenant dans les dépôts officiels. Petit à petit, j'ai rejoins la communauté française, jusqu'à devenir président de son association, Alionet, l'an dernier. J'ai aussi écrit quelques articles, avec l'aide de Seb95 de passionlinux, je traduit et relaie les news du projet openSUSE et je suis régulièrement présent sur le stand openSUSE lors des événements du Libre en France.

Et pourquoi je voudrais candidater au conseil openSUSE alors ?

Eh bien, simplement parce que c'est un projet qui me plaît. Je prends plaisir à y contribuer, c'est simple et accueillant, même quand j'ai fait des erreurs lors de la construction de mes premiers paquets les discussions étaient ouvertes et détendues, chose parfois rare dans le Libre. Je n'ai pas non plus trouvé de guerres de chapelles dans ce projet, ou moins qu'ailleurs il m'a semblé. Faire acte de candidature est donc pour moi un moyen de rendre à ce projet ce que j'ai pu en apprendre et c'est aussi une façon de démontrer mon intérêt et qu'il compte pour moi.

Si je venais à être élu au sein du Conseil, il y a deux sujets sur lesquels je souhaite plus particulièrement travailler:

  • le lien avec les communautés d'utilisateurs: comment les encourager et les accompagner à contribuer ? comment mieux coopérer avec les groupes d'utilisateurs existants ?
  • il y a eu de nombreuses discussions très intéressantes sur la forme juridique du projet il y a plusieurs mois. Si ces sujets sont encore d'actualité, je souhaite m'y pencher. Réfléchir et travailler à la transformation d'un tel projet sera sûrement une expérience passionnante.

Vous pouvez trouver plus d'infos sur mes contributions sur:

Si vous êtes membre du projet, je vous encourage à vous intéresser au processus d'éléctions en cours, voire même à vous présenter également!

Lire plus...

Revue Tumbleweed de la semaine 52

05 janvier, 2019 — sogal

Le rythme des snapshots a été un peu plus calme et c'est donc seulement 5 clichés qui ont été publiés fin 2018. N'avaient pas encore été couverts dans des revues antérieures les instantanés 1213, 1214, 1218, 1219 et 1224. Après cela, un soucis dans OBS nous a forcé à faire une pause et à ne pas créer de nouveaux instantanés.

Quoi qu'il en soit, les quelques modificiations qui ont été publiées avec ces 5 instantanés sont:

  • Mesa 18.3.1 (mise à jour 18.1.x)
  • Qt 5.12.0
  • Noyaux Linux 4.19.8 et 4.19.11
  • Mozilla Firefox 64.0
  • Applications KDE 18.12.0
  • KDE Frameworks 5.53.0
  • Passez à LLVM 7
  • Perl 5.28.0

Vitesse lente donc mais impact important. C'est bien de voir qu'autant de piles majeures ont pu être mises à jour / soumises / testées / publiées avant la fin de l'année.

Mais, comme vous en avez certainement l'habitude, openSUSE Tumbleweed ne serait pas appelé « rolling-release stable » s'il n'y avait pas beaucoup d'autres choses en attente. Et stable signifie que nous ne publions pas d'instantanés tant que les tests openQA soient réussis. Il y aura donc des mises à jour majeures à prévoir dans les prochains jours / semaines:

  • Nouveau design de l'installateur: la barre latérale revient, indiquant où on se trouve le processus d'installation. Ceci est déjà vérifié dans Factory et prendra un peu de temps pour tout bien régler dans openQA. C’est aussi la raison principale pour laquelle aucun nouvel instantané n’a lieu pour le moment.
  • glibc 2.28, Python 3.7, openssl 1.1.1: toujours en attente pour l'instant dans la mesure où Python 3.7 est connu pour être incompatible avec Salt. De plus, certains cycles de construction dans Factory rendent presque impossible sa mise à jour en 3.7.
  • Noyau Linux 4.20.
  • tcl 8.6.9, qui casse actuellement la suite de tests de sqlite3.

Tags: opensuse

Nouvelles d'openSUSE Tumbleweed - Semaine 50

17 décembre, 2018 — sogal

Au cours de la semaine 50/2018, Tumbleweed a reçu 4 instantanés: 1206, 1208, 1211 et 1212. Les principales modifications concernent les paquets suivants :

  • Noyau Linux 4.19.7
  • Ruby Rails 5.2.1.1 (modifications liées à CVE)
  • Guile 2.2.4, mis à jour depuis la branche 2.0
  • util-linux 2.33
  • Mise à jour du thème XFCE4, comme annoncé dans la liste de diffusion.

Il reste toutefois quelques « gros morceaux » en attente, même si certains font des progrès mineurs :

  • glibc 2.28, Python 3.7, openssl 1.1.1 : le principal paquet bloquant, qui empêchait les paquets en attente de construire, a pû être identifié (perl5.28 provoquait une boucle sans fin dans makeinfo lors de l'exécution). La zone de staging est encore loin d’être prête, Python 3.7 étant notoirement incompatible avec Salt.
  • Mesa 18.3
  • LLVM7: échec de la construction de Rust avec LLVM7
  • Nouvelle design de l'installateur : la barre latérale revient (indiquant où se trouve actuellement le flux de travail d'installation)
  • PostgreSQL 11
  • Noyau Linux 4.19.8
  • Perl 5.28
  • Qt 5.12.0
  • Applications KDE 18.12.0

On dirait que la liste des changements en attente s'allonge de semaine en semaine, en partie du fait que de plus en plus de développeurs semblent, et c'est bien normal, occupés à préparer leurs vacances. Mais il y a en encore bien assez pour que Tumbleweed continue de rouler ! :)

Tags: opensuse

Partition utilisateur dans un volume btrfs

12 décembre, 2018 — sogal

btrfs est un système de fichier moderne, donné pour être le remplaçant du veillissant, mais toujours très fiable et très utilisé, ext4. Il est le choix de base de la proposition de partitionnement par défaut lors de l'installation d'openSUSE pour la partition racine. La partition /home, si l'utilisateur fait le choix d'en créer une séparée, est en xfs.

On a entendu beaucoup de chose sur l'usage (ou le mésusage selon les cas) de btrfs avec notamment des problèmes dûs aux scripts de maintenance (présents dans /usr/share/btrfsmaintenance/ et lancés par leur timers systemd respectifs). Il faut reconnaître que les opérations de scrub et de balance des blocs ralentissent, parfois, considérablement le système durant un instant. Et plus on attend pour le faire (ex. d'un système n'étant pas utilisé souvent et, à chaque utilisation, recevant une grande quantité de données sur le disque), plus il y a de travail à faire et cela peut durer jusqu'à 5 minutes, durant lequel la machine est très ralentie, voire peut apparaître bloquée. Je ne vais pas revenir là-dessus, ce sujet a été abordé maintes fois à grand coup de trolls, de mauvaise foi et d'arguments non factuels à plusieurs endroits.

Dans ce billet, je voudrais juste partager un retour d'expérience, positif, sur l'usage de btrfs non seulement sur la partition racine, mais également dans ma partition /home. En effet, j'ai décidé il y a plusieurs semaines de convertir ma partition xfs (proposition de base de l'installeur openSUSE) en btrfs afin de profiter des snapshots.

Pour ce faire, j'ai commencé par passer en runlevel 3 :

init 3

J'ai fait une sauvegarde de mon /home actuel sur un disque externe :

rsync -arv --progress /home/ /run/media/user/DISK_BACKUP/

Ceci fait, j'ai démonté mon /home :

umount /home

Puis formater la partition en btrfs. Notez ici que si ça avait un système de fichier de type ext2/3/4 ou reiserfs, j'aurai pu tout simplement le convertir en btrfs, sans perte de données, via la commande btrfs-convert -p -l home /dev/partition_home. Pour formater la partition donc :

mkfs.btrfs -L home /dev/partition_home

Ceci fait, ne pas omettre de modifier le /etc/fstab pour refléter le changement de système de fichier. J'ai ensuite créé un sous-volume btrfs au nom de mon utilisateur :

btrfs subvolume create /home/user

Dans lequel j'ai activé les snapshots, but de toute l'opération :

snapper -c home create-config /home/user

Ceci va me créer une configuration pour snapper, l'utilitaire en charge de gérer la création et la suppression des snapshots, dans /etc/snapper/configs/home que j'ai adapté à mes besoins comme suit :

# nom du sous-volume dont il faut prendre un instantané
SUBVOLUME="/home/user"

# type du système de fichier
FSTYPE="btrfs"

# btrfs qgroup for space aware cleanup algorithms
QGROUP=""

# part du système de fichier que les instantanés peuvent utiliser
SPACE_LIMIT="0.5"

# utilisateurs et groupes autorisés à faire usage de cette configuration
ALLOW_USERS="user"
ALLOW_GROUPS=""

# synchroniser les droits des utilisateurs et les groupes définis ci-dessus
# avec le répertoire .snapshots
SYNC_ACL="yes"

# démarrer la comparaison des snapshots -pre et -post en arrière-plan après
# la création du snapshot -post
BACKGROUND_COMPARISON="yes"

# exécuter le nettoyage quotidien, basé sur l'algorithme du nombre d'instantané
NUMBER_CLEANUP="yes"

# limite pour le nettoyage quotidien, basé sur l'algorithme du nombre d'instantané
NUMBER_MIN_AGE="1800"
NUMBER_LIMIT="50"
NUMBER_LIMIT_IMPORTANT="10"

# créer des instantanés horaires (oui, c'est bien le but de ma manœuvre)
TIMELINE_CREATE="yes"

# nettoyer les instantanés horaires après un certain temps
TIMELINE_CLEANUP="yes"

# limites pour le nettoyage de la timeline (les instantanés horaires)
# âge minimum de l'instantané
TIMELINE_MIN_AGE="1800"
# nombre d'instantanés horaires à conserver au maximum
TIMELINE_LIMIT_HOURLY="24"
# nombre d'instantanés journaliers à conserver au maximum
TIMELINE_LIMIT_DAILY="14"
# nombre d'instantanés hebdomadaire à conserver au maximum
TIMELINE_LIMIT_WEEKLY="4"
# nombre d'instantanés mensuels à conserver au maximum
TIMELINE_LIMIT_MONTHLY="3"
# nombre d'instantanés annuels à conserver au maximum
TIMELINE_LIMIT_YEARLY="0"

# lancement du nettoyage des paires d'instantané -pre et -post vide
EMPTY_PRE_POST_CLEANUP="yes"

# âge minimum des instantanés nettoyés par l'algorithme pre-post
EMPTY_PRE_POST_MIN_AGE="1800"

Ainsi je vais pouvoir disposer d'instantanés me permettant de remonter dans le temps si jamais je fais une fausse manip' et efface des fichiers par erreur ou autre bêtise. Et les instantanés de la partition système me permettent, depuis le menu de démarrage de GRUB de sélectionner de démarrer sur un instantané en lecture seule afin de pouvoir réparer mon système en cas de soucis.

J'utilise ce setup avec deux partitions en btrfs, une pour le système, une pour mes données, chaque d'elle disposant de leur fréquence de création d'instantanés, depuis plusieurs mois sur une machine que j'utilise au quotidien. Et je dois dire que j'en suis très content ! Je n'ai pas eu de soucis de ralentissements agaçants, les instantanés sont bien créés puis supprimés conformément à la configuration, bref, impeccable !

Tags: opensuse

openSUSE Leap 15.0 est sortie !

02 décembre, 2018 — sogal

Aujourd'hui vendredi 25 mai, c'est la sortie d'openSUSE Leap 15.0 !

Au menu de cette release :

  • un nouveau rôle de serveur transactionnel permettant des mises à jours atomiques ;
  • GNOME 3.26 ;
  • Utilisation de Wayland par défaut (mais Xorg reste disponible) ;
  • Un nouveau partitionnement Btrfs utilisant la libstorage-ng ;
  • firewalld remplace SuSEFirewall ;
  • bien d'autres nouveautés (voir les release notes )

Et pendant que vous lirez ces lignes, je serai à Prague, en train de visiter et d'assister la conférence openSUSE 2018 et de fêter cette sortie !

Have a lot of fun !

Tags: opensuse

Réduire la taille d'un volume système en RAID1

02 décembre, 2018 — sogal

Lors de l'installation de ma station de travail en openSUSE Leap 42.3, je n'avais pas créé de partition /home dédiée, n'en ayant alors pas l'utilité. Mes besoins ayant changé, me voici avec une partition racine sur un RAID1 qu'il va me falloir réduire sans perte de données, car je n'ai pas l'intention de réinstaller. Je partage ici la procédure que j'ai suivie dans l'espoir qu'elle puisse vous être utile.

Le contexte :

  • Un RAID1 nommé /dev/md127 composé de /dev/sda3 et /dev/sdb3
  • ... d'une taille de de 216 Go
  • ... contenant un système de fichiers au format btrfs
  • ... que je veux réduire à 51 Go (soit 10 Go de plus que la taille actuellement consommée)
  • ... dont les partitions débutent, sur leur disque respectif, à 8.5 Go.

Préparation :

Bien entendu, afin de pallier tout problème éventuel, j'ai fait une sauvegarde complète de mon /home :

rsync -arv --progress /home/ /run/media/sogal/MyDisk/homebak/

Et j'ai testé ma procédure par deux fois dans une machine virtuelle reproduisant le contexte énoncé précédemment.

Puis j'ai lancé l'utilitaire btrfs de défragmentation sur / au cas où :

btrfs filesystem defragment -r -v /

Ceci étant fait, je peux passer à la phase du redimensionnement proprement dit. Pour cela, il me faut un système live, j'ai pris la dernière Linux Mint, seule ISO Live récente que j'avais sous la main, avec laquelle j'ai créé une clé USB bootable.

La procédure :

  1. Démarrer sur la clé USB ;

  2. Installer les utilitaires de gestion RAID nécessaires :

    apt-get install mdadm
    
  3. Charger les modules nécessaires :

    modprobe mdio
    modprobe linear
    modprobe multipath
    modprobe raid0
    modprobe raid1
    modprobe raid5
    modprobe raid6
    modprobe raid10
    
  4. Chercher les volumes RAID présents :

    mdadm --examine --scan
    
  5. Activer les volumes RAID trouvés :

    mdadm -A --scan
    
  6. Monter le volume RAID1 à réduire :

    mount /dev/md127 /mnt
    
  7. Redimensionner le système de fichiers :

    btrfs filesystem resize -165G /mnt
    

    Cette opération a pris un bon moment, laisser le travail se faire !

  8. Une fois le système de fichiers btrfs réduit, démonter le volume RAID1 :

    umount /mnt
    
  9. Mettre une des partitions en échec :

    mdadm /dev/md127 --fail /dev/sda3
    
  10. Puis la retirer du RAID :

    mdadm /dev/md127 --remove /dev/sda3
    
  11. Redimensionner la partition un poil plus grand que le système de fichiers :

    parted /dev/sda → resizepart 3 → end 60GB→ Yes → quit
    
  12. Vérifier le système de fichiers :

    btrfs check /dev/sda3
    

    Il va renvoyer une série de messages qui ne veulent pas dire que le système de fichiers est corrompu, pour s'assurer de la réussite du test, vérifier son code de retour :

    echo $?
    

    si c'est 0, c'est tout bon.

  13. Réduire le volume RAID1 à une taille légèrement inférieure à celle des partitions qui le composent (j'ai mis 500 Mo de moins) :

    mdadm --grow /dev/md127 --size=xxxx
    

    où xxxx = taille souhaitée en GB * 1024 * 1024

  14. Rajouter le disque au RAID :

    mdadm /dev/md127 --add /dev/sda3
    
  15. Attendre la reconstruction du volume RAID1, visible en lançant :

    cat /proc/mdstat
    
  16. Faire pareil avec l'autre partition (/dev/sdb3 dans mon cas) (étapes 8 à 14 mais pas la 13 !)

  17. Agrandir le volume RAID1 au maximum de la nouvelle taille des partitions qui le composent :

    mdadm --grow /dev/md127 --size max
    
  18. Redémarrer sur votre système habituel :

    reboot
    

Le résultat :

Au redémarrage sur ma Leap, rien à signaler, mes disques /dev/sda et /dev/sdb disposent maintenant d'un espace libre de 165 Go dans lequel j'ai pu créer, respectivement les partitions /dev/sda4 et /dev/sdb4 que j'ai ajouté à un nouveau volume RAID1 (chiffré pour le coup) dans lequel j'ai transféré mon /home.

Enjoy !

Tags: tips, opensuse

openSUSE en quelques questions

30 novembre, 2018 — sogal

De retour des JDLL, une petite présentation reprenant les questions qui revenaient le plus souvent sur openSUSE. Les 24 et 25 mars derniers, je tenais le stand openSUSE aux Journées du Logiciel Libre et force est de constater que cette distribution est très mal connue en France, aussi bien des débutants (ce qui peut sembler normal) que d'utilisateurs avec plus d'expériences de l'univers GNU/Linux. À l'issue du week-end, j'ai donc fait une présentation .odp présentant (très rapidement, ce n'est pas du tout exhaustif) les deux distributions créées par le projet openSUSE ainsi que leurs points forts les plus saillants.

Le .pdf de la présentation est disponible ici :

2018-Presentation_openSUSE.pdf

Enjoy !

Tags: opensuse

Comment sont choisies les versions du kernel d'openSUSE Leap ?

30 novembre, 2018 — sogal

Linux

La prochaine version d'openSUSE Leap, numérotée 15, pointe son nez et on sait d'ores et déjà qu'elle bénéficiera du noyau Linux en version 4.12. Cela pourrait en étonner plus d'un et on serait en droit de se demander pourquoi un tel choix alors que la version courante du noyau est 4.15 ou si, au court de sa vie, le noyau de Leap 15 pourra être mis à jour afin de ne pas rester avec un noyau jugé trop ancien.

Cette question a été posée sur la liste de diffusion opensuse-factory et un des participants très informé à bien voulu prendre le temps de donner une réponse claire et complète qu'il paraît important de retransmettre. Le texte qui suit en est donc une traduction et une adaptation au format « article » libres.

Pourquoi Leap 15 aura le noyau 4.12 au lieu de la version 4.14 (ou ultérieure) ? (par Peter Linnell)

Il faut tout d'abord rappeler que la distribution openSUSE Leap bénéficie d'une base de code partagée avec la version professionnelle SLE (Suse Linux Enterprise), base dont le noyau fait partie. À cet égard, il faut beaucoup de temps pour que le noyau obtienne les certifications requises pour fonctionner sur les matériels des clients de Suse et avec les logiciels d'autres éditeurs professionnels. Toutes les étapes permettant une telle certification pour le noyau 4.12 auraient dû être retardées ou bien recommencées pour la version 4.14 si celle-ci avait été choisie en finalité. Le travail à fournir afin d'obtenir une telle certification est colossal et coûteux, il nécessite la mobilisation de nombreux ingénieurs et requiert d'avoir à disposition les différents matériels pour lesquels la distribution doit être certifiée.

L'auteur de la réponse initiale rapporte l'exemple du processus de certification d'un serveur type « lame » et d'une armoire de stockage. Il a fallu pour cela mobiliser 3 ingénieurs durant plusieurs jours, assurer le déplacement au travers des États-Unis de 2 experts SUSE (dont l'auteur) pour un total estimé à plus de 10 000 $. Le tout pour certifier un seul type de matériel !

Les membres de la communauté openSUSE ne sont sûrement pas tous conscients du genre de matériel pour lequel est certifiée la SLE (SUSE Linux Enterprise) (ndt: et donc le noyau de la Leap) mais il s'en trouve parmi eux de très exotiques et très chers. On peut citer deux exemples :

  1. Les serveurs SAP HANA qui tournent quasi exclusivement sous SLES (SUSE Linux Enterprise Server). Une image système de 32 To peut absorber jusqu'à 5 ou 6 fois ce volume de données compressées et les contenir en mémoire. Nous parlons là de 150 à 180 To de données disponibles en RAM afin de réaliser des analyses en temps réel ! Pratiquer des tests sur ce genre de monstres nécessite d'une part des semaines d’ingénierie et d'autre part que le fabriquant mette à disposition une machine de plusieurs millions de dollars.

https://www.hpe.com/us/en/solutions/sap-hana.html

  1. Les systèmes SGI, une entreprise rachetée par HPE. Il s'agît de systèmes NUMA (« non uniform memory architecture » ou architecture mémoire non uniforme) pouvant théoriquement gérer jusqu'à 64 To de RAM avec un seul noyau Linux.

https://www.hpcwire.com/2016/05/11/t...life-sciences/

En ce qui concerne les logiciels, certaines piles logicielles éditées par les fabricants peuvent prendre des semaines pour être certifiées. Les fabricants eux-mêmes peuvent réaliser des tests de résistance ou des contrôles qualité afin de s'assurer que tout est conforme. Après tout, les éditeurs de logiciels fournissent un certain niveau de garantie à leurs clients en ce qui concerne la compatibilité et la stabilité qu'ils se doivent de maintenir. Un problème dans leurs logiciels pourrait entraîner un manque à gagner considérable pour leurs clients.

Donc, du point de vue de l'entreprise, la décision que telle version du noyau sera utilisée met en branle une machinerie complexe, requérant une grande coordination, en interne mais aussi avec les clients et partenaires. Ce genre de décision n'est donc pas pris à la légère.

En tant que membres de la communauté openSUSE, nous avons donc de la chance de bénéficier d'une telle ingénierie. Ce sont littéralement des millions de dollars d'investissement qui, non seulement sont mis à disposition dans Leap, mais qui démontre bien la volonté affirmée de SUSE de voir openSUSE réussir et de l'intérêt que l'entreprise porte à notre communauté.

Pour conclure, il faut rappeler, si besoin, que le noyau, bien qu'en version 4.12 bénéficiera des rétro-portages (« backports ») tout au long de sa durée de vie en vue d'apporter des correctifs et d'améliorer la prise en charge matérielle et logicielle.

Tags: opensuse

openSUSE Leap 42.3 est sortie !

29 novembre, 2018 — sogal

openSUSE Leap 42.3 est sortie officiellement aujourd'hui. Cette version est une version mineure de la série 42, elle apporte peu de changement dans la base du système mais rafraîchit l'ensemble de paquets. Pas de révolution donc pour Leap, la version "conservatrice" de la distribution au caméléon, mais ses points forts le sont encore plus !

Voici quelques extraits de l'annonce de sortie :

Toujours plus stable : Après avoir déjà ajouté de code source de SLE 12 dans Leap 42.2 par rapport à la 42.1, Leap 42.3 va plus loin en intégrant encore d'avantage de paquets de SLE 12 SP 3 et en synchronisant de nombreux paquets communs. Prête à être utilisée comme serveur : openSUSE Leap 42.3 offre la possibilité de sélectionner un profil Serveur durant l'installation. Sans environnement graphique, une installation serveur de Leap est prête à effectuer tout ce que vous attendez.

Idéale pour les développeurs et surtout les administrateurs systèmes.

Pour tous les utilisateurs : elle intègre des versions stabilisées et éprouvées des environnements de bureaux les plus répandus, dont principalement KDE Plasma 5.8 LTS et GNOME 3.20. Aucun problème pour jouer sous Linux, Steam et PlayOnLinux peuvent être installés très simplement.

Pour fêter ça, j'ai arboré fièrement mon plus beau t-shirt 😄 :

openSUSE Tshirt

et j'ai fait la mise à jour de mon poste de travail, directement en ligne par le réseau (certains préfèrent passer l'ISO) :

Vérification des dépôts actifs :

zypper lr -u

Suppression des dépôts inutiles :

zypper rr n°_du_dépôt

Ou désactivation :

zypper mr -d n°_du_dépôt

Copie des anciennes sources (au cas où) :

cp -Rv /etc/zypp/repos.d /etc/zypp/repos.d.Old

Changement de version des dépôts :

sed -i 's,42\.2,42.3,g' /etc/zypp/repos.d/*

Rafraîchissement des dépôts et des clés GPG :

zypper --gpg-auto-import-keys ref

Là je suis passé en console (tty) puis en runlevel 3 (par précaution) :

init 3

Et on lance la mise à jour :

zypper dup

Enfin, on redémarre :

reboot

Une heure après environ, c'était fait et me voilà avec un système mis à jour de façon complètement transparente, sans rien casser ni dérégler, j'ai pu reprendre mon travail dans la foulée.

J'utilise openSUSE quasi exclusivement depuis 8 mois maintenant, au travail comme à la maison, et je dois dire que j'en suis ravi. La facilité avec laquelle j'ai effectué cette mise à jour me conforte encore dans ce choix et dans mon impression de distribution professionnelle. Elle est malheureusement trop peu représentée en France et je trouve cela dommage. J'encourage donc les utilisateurs, particuliers ou professionnels, à la recherche d'un système d'exploitation fiable, stable sans être trop longtemps figé, simple à prendre en main et à gérer (merci Yast) à télécharger cette nouvelle version, à la tester et à rejoindre la communauté des utilisateurs francophones .

Enjoy !

Tags: opensuse

Changer de distrib : un comparo Debian / CentOS / openSUSE

29 novembre, 2018 — sogal

En recherchant il y a quelques mois une nouvelle distribution pour mon ordinateur professionnel, j'ai (re)découvert openSUSE. Quelques mois après, je vous propose ici mon retour d'expérience.

Pourquoi changer ?

Jusqu'à présent j'utilisais Debian, ma distribution de choix depuis 2012. J'en étais jusqu'à très content, j'ai passé plus de 2 excellentes années sous Wheezy, version grâce à laquelle j'ai appris et expérimenté énormément de choses, puis 1 an et demi sous Jessie. J'ai rencontré un peu plus de petits désagréments avec Jessie. Rien de grave mais je me suis moins éclaté qu'avec Wheezy. Bref, depuis début 2016, la société dans laquelle je travaille utilise Fedora sur les postes clients. Avec plusieurs mois de retard, je me suis mis, j'ai d'ailleurs rédigé un billet là-dessus. Ce n'est pas un mauvais système mais 2 choses principalement m'ont déplu :

  • le cycle de release, trop rapide. Qui a dit "obsolescence programmée" ? ;)
  • le gestionnaire de paquet, dnf, que je n'apprécie pas, le trouvant trop pataud.

Je voulais donc autre chose, une distribution équilibrée, avec un cycle de release décent (annuel, pas moins) tout en disposant d'ensemble de paquets pas trop vieux et contenant tous les outils professionnels dont j'ai besoin.

Choisir et tester :

Avec ces considérations en tête, le tour a été relativement vite fait et j'ai établi un comparatif entre 3 distributions :

  • Debian (stable évidemment) ;
  • CentOS 7 ;
  • openSUSE Leap 42.2 (qui était alors à 2 semaines de sa sortie en stable).

J'ai monté 3 machines virtuelles, établi une grille de critères reprenant, entre autres ceux, énoncés ci-dessus et essayé ces 3 systèmes dans tous les sens, avec des configurations égales (autant que possible) et en essayant les mêmes paquets.

Dépôts Debian

Le projet Debian fournit très clairement l'ensemble de paquets le plus complet et le plus cohérent (j'entends par là qu'ils sont tous dans un seul dépôt (jusqu'à 3 si on active contrib et non-free).

Dépôts CentOS

Les dépôts de base de CentOS m'ont paru plus "pauvres" mais contiennent la très grande majorité des outils nécessaires sur un poste de travail. La "fraîcheur" des versions est variable, mais à l'image d'une Debian stable dans l'ensemble. Un certain nombre d'outils plus spécifiques requièrent l'ajout du dépôt EPEL. Je n'ai pas apprécié l'utilisation de yum que je trouve assez lent dans l'ensemble, surtout comparé à apt (apt-get) qui est tout de même très rapide.

Dépôts openSUSE

Les dépôts d'openSUSE se répartissent en 4 catégories :

  • les dépôts officiels, avec des branches libres et non-libres, équivalentes à main et non-free chez Debian ;
  • les dépôts communautaires qui contiennent des paquets ne pouvant être incorporés dans les dépôts officiels, souvent pour des raisons de licences, par exemple le dépôt Packman qui contient les codecs nécessaires pour lire des vidéos (aux formats mp4, avi etc...) ;
  • les dépôts "spécialisés" qui regroupent des paquets de même catégorie (applis pour environnement Gnome, applis pour graphisme, applis en console etc...) ;
  • les dépôts "home", équivalents aux dépôts Copr de Fedora, qui hébergent les paquets créés par des particuliers.

Le dépôt officiel libre contient tous les logiciels dont j'aurai besoin donc pas besoin d'avoir recours aux autres, à l'exception de Packman. Concernant ce dernier, il est amusant de constater que certains projets séparent les codecs "litigieux" (mp3, mp4 etc...) et d'autres non, c'est le cas de Debian par exemple.

Les installeurs

Un des aspects importants lorsqu’on installe un OS c’est... l’installeur pardi ! Installer successivement ces trois distributions fut l’occasion de comparer les installeurs et ils sont vraiment très différents !

L’installeur Debian est simple et direct (je l’utilise en mode texte mais le mode graphique est similaire et n’offre rien de plus). Il ne permet pas de paramétrer grand chose, juste l’essentiel. Et surtout il ne faut pas avoir à installer en comptant sur une connexion wifi. C’est un peu la croix et la bannière pour tenter de fournir un pilote de carte wifi via un supporte externe durant le processus d’installation. Cela dit, il est rapide et en gros, ça s’installe en cliquant successivement sur la touche Entrée.

L’installeur de CentOS, Anaconda, qui est le même que celui de Fedora, est pareil, basique, très axé serveur. Il propose plusieurs profils d’installation pour serveurs spécialisés ou pour stations de travail, ce qui est sympa pour fournir une base prête à l’emploi. J’ai moins apprécié la partie partionnement que j’ai trouvé moyennement intuitive.

L’installeur d’openSUSE est de très loin le plus complet. C’est le plus long à se lancer mais il permet de tout configurer avant installation. On peut ainsi configurer finement la partie réseau, l’outil de partitionnement est très complet (c’est le même module qu’on retrouve par la suite dans Yast). Et chose très appréciable, il permet également de choisir chacun des paquets à installer. Pour l’exemple j’ai sélectionné une base «Bureau Gnome» puis j’ai ajouté tous les logiciels complémentaires que je veux et retiré ceux qui me sont inutiles. J’ai vraiment apprécié cette possibilité, ça évite d’installer des paquets pour les supprimer 5 minutes plus tard et de démarrer avec un système contenant tous les outils que l’on veut.

Sur chacune des machines virtuelles j’ai tenté de reproduire une configuration identique, à base de bureau Gnome et de tester avec quelle facilité je pouvais installer les logiciels que je voulais. À ce jeu, Debian s’en sort le mieux au vu de la taille de sa logithèque, suivi d’openSUSE qui dispose de nombreux paquets et peut être facilement étendue via des dépôts communautaires. CentOS est assez loin derrière et tout n’était pas toujours disponible.

Ce qui m’amène à évoquer brièvement les gestionnaires de paquets.

Les gestionnaires de paquets

Debian avec apt est le «flash» de l’équipe. Il se lance et exécute les actions très rapidement. Le rafraîchissement des sources est rapide également. Yum de CentOS est à l’opposé, il est lent à se rafraîchir et parfois semble se bloquer plusieurs longues secondes à la fin d’une installation, avant de rendre la main. Zypper dans Leap est relativement rapide, moins qu’apt, mais j’ai trouvé que c’était le plus lisible. La coloration syntaxique permet de bien se repérer dans les noms de paquets (la première lettre de chaque est en couleur) et les informations importantes relatives aux modifications apportées sont bien mises en avant.

Bon, faut se décider !

J’utilisais Debian depuis 4 ans et j’avais, il faut bien le dire, envie de changer et de découvrir (vraiment, pas juste le temps d’un test d’une heure en VM) une autre distribution. Les tests semblaient montrer qu’openSUSE pourrait répondre à mes besoins alors pourquoi pas. J’avais déjà fait usage au travail d’openSUSE en 13.1 et 13.2. Je n’avais pas été 100% conquis alors mais les retours lus ici et là sur cette nouvelle mouture qu’est la Leap m’ont conforté dans ce choix, c’est donc parti pour l’installation en réel.

Here we go !

L’installation s’est très bien passée. Bien que je déplore l’existence de pilotes privateurs pour les cartes wi-fi (les seuls qui m’importent vraiment, n’étant pas un joueur assidu sur PC), force m’est de reconnaître qu’il est difficile de s’en passer et leur inclusion par défaut dans l’installeur d’openSUSE m’a facilité la vie. Le gestionnaire de partitionnement est très complet et j’ai pu configurer très simplement mes volumes LVM chiffrés. C’est lors du résumé des options d’installation que j’ai pu choisir plus finement mes paquets, en supprimant les paquets qui me sont inutiles (jeux, gnome-document, gnome-musique etc...) et ajouter ma sélection (notamment Terminator, CherryTree et Keepassx). Un dernier clic et c’est parti, l’installeur fait son boulot et lorsque je reviens 20 min plus tard, mon PC a redémarré et est prêt à l’emploi !

Et alors, c’est bien openSUSE ?

La Leap 42.2 est une distribution moderne et stable. Donc oui, c’est bien, ça fait son travail, ça s’allume le matin, s’éteint le soir et entre les deux je n’ai pas eu de problèmes. En parlant de Gnome, je tiens à signaler l’excellente intégration de celui-ci. Historiquement openSUSE est considérée comme une distribution pro-KDE mais Gnome est parfaitement intégré et très bien fini. Le fait que la SLE (Suse Linux Entreprise) utilise Gnome (dans sa version Classique) comme bureau n’y est peut-être pas étranger. J’ai notamment apprécié de trouver l’ensemble des outils visant à configurer le système directement intégrés aux Paramètres Gnome :

Yast dans Gnome

Yast, l’outil historique d’openSUSE permettant de configurer son système graphiquement, est intéressant. Je ne suis pas particulièrement pro « utilitaires monolithiques et graphiques de configuration » car ils ont tendance à masquer la réalité et ne permettent pas d’apprendre à bien éditer des fichiers de configuration, à avoir les bonnes pratiques dans ce cas (faire une copie avant édition...). Néanmoins, sa présence n’oblige pas à l’utiliser d’une part et n’empêche pas du tout l’édition directe des fichiers de configurations d’autre part. Ainsi un-e débutant-e pas encore à l’aise pourra quand même gérer aisément certains aspects de son système. Sur ce point, je trouve que le nombre de modules Yast inclus par défaut dans une installation de type « Desktop » un poil trop important. Qui a besoin de gérer des périphériques ISCSI ou des clients NIS sur son portable perso ? Yast est en revanche très pratique lorsqu’on reprend l’administration de serveurs.

En conclusion, ce changement et ces tests m’ont permis de bien définir mes besoins et les logiciels y répondant, de comparer 3 distributions majeures et toutes très bonnes. Si je prends autant de plaisir à utiliser openSUSE c’est surtout qu’elle sait se faire complètement oublier, me permettant ainsi de me consacrer à mon travail.

J'espère que ce petit tour d'horizon vous aura donné envie de tester l'une de ces trois distributions et notamment openSUSE, distribution de qualité mais moins connue en France. Des membres de la communauté openSUSE France en expliquent les raisons dans une interview accordée à Framasoft : OpenSUSE, une distribution méconnue.

Tags: linux, opensuse