Et oui, tester Fedora, c'est aussi tester et aider les projets libres qu'il met à disposition afin de rendre le tout meilleur. Or, Mozilla Firefox est le navigateur par défaut de Fedora, l'un des plus utilisés de la communauté et personnellement c'est celui de mon quotidien depuis ses débuts en 2004.

Et actuellement Firefox a besoin d'un petit coup de main pour accélérer le déploiement d'une nouvelle technologie : Electrolysis.

Vous avez 5-10 minutes et vous aimez Firefox ? Cet article est fait pour vous !

Qu'est-ce que Electrolysis ?

Le concept est que Firefox soit multiprocess. Pas un processus par onglet mais dans un premier temps pour séparer la gestion des pages web de l'interface du navigateur. Cela devrait améliorer la fluidité dans un certain nombre de cas, mais aussi améliorer la stabilité de l'ensemble en évitant que le navigateur crash entièrement à cause d'un site web mal conçu.

C'est un projet complexe à mettre en œuvre car remettant en cause l'ancienne architecture du navigateur. Cela fait plusieurs mois voire années que ce chantier est en cours.

Et si Electrolysis se déploie de plus en plus, cela se fait par vagues et il est nécessaire d'aider pour que la diffusion soit totale le plus vite possible. En effet, Firefox n'active pas ce mode si l'utilisateur a au moins une extension dont on ignore la compatibilité avec ce changement. Or, il y a beaucoup d'extensions dont le status n'est pas connu. En plus du fait que Firefox repose aujourd'hui énormément sur sa collection d'extensions.

Vous pouvez voire manuellement sur ce site si vos extensions sont compatibles ou non avec ce mécanisme. Sachant que seuls ceux contenant le champs compatible le sont.

Comment aider ?

Tout d'abord, vérifiez si Electrolysis n'est pas déjà activé. Pour cela saisissez about:support dans la barre d'adresse. Cherchez le champs Fenêtres multi-processus. Si vous avez 1/1, il est déjà activé et vous n'avez rien de spécial à tester. Si c'est 0/1, vous pouvez poursuivre la lecture.

Ensuite, il suffit de forcer Electrolysis, d'utiliser Firefox et de faire un retour plus tard sur si cela s'est bien ou mal passé. Pour aider, il est préférable d'avoir la version 51.0 ou supérieur de Firefox.

Pour forcer Electrolysis, vous devez aller dans le about:config (à saisir dans la base d'adresses). Ensuite un clique droit pour créer une nouvelle valeur booléenne avec pour nom browser.tabs.remote.force-enable. Vous mettrez la valeur à True.

Ensuite, il est nécessaire d'installer l'extension Add-On compatibility reporter. Vous pouvez redémarrer Firefox et le tester.

Soyez naturels, utilisez Firefox normalement pendant quelques heures voire jours. Testez évidemment vos extensions. Si vous le voyez aucun soucis, vous pouvez utiliser l'extension pour déclarer toutes vos extensions comme compatibles. Sinon il faut éventuellement en désactiver certaines pour déceler celle qui pose soucis.

Si une extension pose problème, n'hésitez pas à contacter son auteur pour qu'il soit au courant et qu'il corrige cela.

Vous pouvez désactiver Electrolysis si vous le souhaitez en remettant browser.tabs.remote.force-enable à False.

Et voilà, vous avez fini. Grâce à votre retour, de plus en plus d'extensions seront validées et Electrolys pourra fonctionner sur de plus en plus de machines par défaut, dont vos machines.

Original post of Renault.Votez pour ce billet sur Planet Libre.

Mais pourquoi chiffrer d'abord ?

- name: "Dépot d'un template de création"
template:
src: "template.sh.j2"
dest: "/tmp/creation.sh"
register: _

- name: "Exécution du template"
shell: "/tmp/creation.sh"
when: _.changed|d('no')|bool

Utilisation du 3DES pour chiffrer

import sys, os, base64
from Crypto.Cipher import DES3

BS    = 8
pad   = lambda s: s + (BS - len(s) % BS) * chr(BS - len(s) % BS) 

key = os.getenv('DES_KEY')
des = DES3.new(key, DES3.MODE_ECB)
print(base64.b64encode(des.encrypt(pad(sys.argv[1]))))

$ DES_KEY=111111111111111111111111 ./chiffre.py abcdefghijklmnopqrstuvwxyz
eHPtqHbKD+oGdodkRUxdwo8Z4EcsTUBrrSeCYcBIQ0g=

$ DES_KEY=111111111111111111111112 ./chiffre.py abcdefghijklmnopqrstuvwxyz
vD37nk4ME9n5BUa9pLH0zrHGWl2xUkLRlLhEwfkFmos=

import sys, os, base64
from Crypto.Cipher import DES3

BS    = 8
unpad = lambda s: s[0:-ord(s[-1])]

key = os.getenv('DES_KEY')
des = DES3.new(key, DES3.MODE_ECB)
print(unpad(des.decrypt(base64.b64decode(sys.argv[1]))))

$ DES_KEY=111111111111111111111112 ./dechiffre.py vD37nk4ME9n5BUa9pLH0zrHGWl2xUkLRlLhEwfkFmos=

// Récupère un mot de passe (ou autre chose) chiffré avec une clé 3DES et renvoie
// la chaîne à l'aide de la clé contenue dans la variable d'environnement DES_KEY

import javax.crypto.Cipher;
import javax.crypto.spec.SecretKeySpec;
import java.util.Base64;

// Decrypt a password
class dechiffre {
public static void main(String [] args) throws Exception {
System.out.println(decrypt(args[0]));
  }
public static String decrypt(String password) throws Exception {
String env_key = System.getenv("DES_KEY");

Cipher out_cipher = Cipher.getInstance("DESede/ECB/PKCS5Padding");
SecretKeySpec key = new SecretKeySpec(env_key.getBytes(), "DESEDE");
    out_cipher.init(Cipher.DECRYPT_MODE, key);
return new String(out_cipher.doFinal(Base64.getDecoder().decode(password)), "UTF-8");
  }
}

$ DES_KEY=111111111111111111111112 java dechiffre vD37nk4ME9n5BUa9pLH0zrHGWl2xUkLRlLhEwfkFmos=

$ export DES_KEY=111111111111111111111112
$ echo vD37nk4ME9n5BUa9pLH0zrHGWl2xUkLRlLhEwfkFmos= | \\

    openssl des-ede3 -d -a -K $(echo -n "$DES_KEY" | xxd -pu)

abcdefghijklmnopqrstuvwxyz

- name: "Dépot script"
template:

    scr: "test.sh.j2"

    dest: "/tmp/monscript.sh"

  environment:

    encrypted_value: "vD37nk4ME9n5BUa9pLH0zrHGWl2xUkLRlLhEwfkFmos="

- name: "Rafraichir configuration"
shell: "/tmp/monscript.sh"
environment:
DES_KEY: "{{des_key}}"

#!/bin/bash
mdp=$(echo {{encrypted_value}} | openssl des-ede3 -d -a -K $(echo -n "$DES_KEY" | xxd -pu) &> /dev/null) && echo $mdp

$ ./test.sh

$ echo $?

1

Original post of Yannig.Votez pour ce billet sur Planet Libre.

Épilogue d’un problème que j’ai mis une bonne dizaine de jours à résoudre, si cela peut en aider d’autres.

Lors du démarrage de mon PC, depuis quelques semaines (mois ?), j’avais un écran noir assez long (1 minute lorsque je me suis décidé à m’attaquer au problème) avant l’affichage du menu Grub. Ce n’est pas la mort, ça permet d’aller aux toilettes pendant que ça démarre mais c’est assez casse-pied et ça doublait mon temps de démarrage : Papa, quand est-ce que tu règles le problème de démarrage ? Dixit mon gamin de 10 ans qui poireaute en attendant de jouer aux jeux vidéos ou de regarder des vidéos et va aux toilettes une fois que c’est démarré.

Bon, il fallait que je m’y attaque ! J’avais pour crainte que ce soit dû à ma carte mère vieillissante (bientôt 8 ans) ou un problème de matériel mal détecté au départ. C’est pourquoi, je suis allé un peu voir dans le BIOS pour vérifier les paramètres, débrancher les cartes annexes, chose qui m’a amenée à mon précédent billet. Sauf que rien de tout ça n’était à mettre en cause puisque, chose que je croyais avoir testée auparavant, le démarrage sur une clé USB ne provoque pas cet écran noir. Pour être sûr que le problème vient de Grub, on peut aussi ajouter un bip au démarrage du grub en décommentant la ligne suivante dans /etc/default/grub :
GRUB_INIT_TUNE="480 440 1"

En cherchant un peu, je n’ai pas trouvé grand chose sur le net, si ce n’est un problème qui semblait similaire mais réglé indirectement ou une ouverture de bug. J’ai donc commencé à chercher un peu plus en détail dans les entrailles de Grub et en allant voir si les autres distributions installées ne mettaient pas le bazar quelque part. Il faut savoir que je travaille en général avec deux partitions de distributions par disque (une opérationnelle, Debian Stable, et une de test, Debian Testing en l’occurrence). Comme je suis passé sur un ssd il y a bien 2 ans, j’ai conservé mes partitions pour tester d’autres distributions afin de voir leur évolution ; j’ai notamment une LMDE que j’installe sur les PC de récup. Bref, j’ai donc 4 distributions sur mon PC (2 sur sda et 2 sur sdb).

Même si la cohabitation entre différentes distributions est bien plus pacifique qu’avec Windows qui tente toujours de reprendre la main, il y a quand même quelques trucs à savoir pour que tout se passe au mieux. Par exemple, je ne veux pas que la distribution de test installe son Grub, mais garder ma distribution principale comme maîtresse et par défaut donc j’empêche son installation (l’installeur me prévient que sans ça, mon système ne sera pas utilisable, oui, je sais ce que je fais). Lorsque ma machine redémarre, je repasse par ma distribution, je fais un update-grub et la nouvelle distribution apparaît dans le menu.

Une autre chose à savoir, c’est que certaines distributions (toutes ?) reformatent systématiquement la partition swap lors d’une installation, ce qui fait que la partition change d’UUID et les autres distributions ne la retrouvent pas. C’est lors du passage à SystemD que je me suis rendu compte de ça car SysVInit passait outre sans erreur critique et je vivais sans Swap (ce qui n’est pas problématique tant que la RAM ne vient pas à manquer) ; avec SystemD, on a par contre une temporisation de 1min30 au cas où la partition a besoin de temps pour être détectée. J’avais alors réglé le problème de la même façon que l’a rapporté récemment Olivyeahh.

Mais revenons à nos moutons, qu’est-ce qui cloche avec Grub ? Déjà, le update-grub mettait un certain temps, pour ne pas dire un temps certain. Celui-ci génère le fichier /boot/grub/grub.cfg qui contient les différentes lignes du menu qui va s’afficher. Quand j’ai vu que celui que j’avais sur ma distro principale faisait 1Mo (celui qui occasionnait 1min d’attente), je me suis dis que le problème venait de là. J’ai donc commencé à réinstaller grub, faire les mises à jour sur les autres distributions tout en éliminant les noyaux obsolètes, j’ai empiré le problème avec des grub.cfg qui atteignaient plusieurs Mo et un démarrage repoussé aux calendes grecques. J’avais bien entendu sauvegardé le grub.cfg initial ; d’ailleurs, on peut aussi tailler à la hache dedans pour éliminer toutes les occurrences inutiles, toute modif est temporaire puisqu’il est regénéré à chaque update-grub.

Après un appel lancé sur Diaspora*, c’est Pkadd (encore merci à lui) qui m’a donné la solution car il avait eu le même problème sur Manjaro. Pour faire bref, et parce que je ne suis pas allé voir le détail, grub-update prend en compte le grub.cfg de chaque distribution, je suppose que le fait d’avoir deux disques fait que selon qu’on soit sur l’un ou l’autre, il pense voir des choses différentes et multiplie les occurrences, ce qui augmente d’une puissance pour chaque distribution pour vite devenir exponentiel. Je ne sais pas si c’est un bug ou si le problème met du temps à venir, mais ça ne m’était pas encore arrivé et je n’ai pas trouvé beaucoup de cas similaires.

La solution est simple, lorsque le temps de boot est encore acceptable (de façon plus sale mais plus expéditive, on peut aussi supprimer tous les grub.cfg, en les renommant et d’appliquer la modif sur chaque partition depuis la distribution principale), il suffit de faire le tour de chaque distribution et d’ajouter dans chaque /etc/default/grub la ligne suivante :
GRUB_DISABLE_OS_PROBER=true
suivi d’un update-grub, chose que je ferai désormais systématiquement sur les installations dont je ne veux pas du grub ; cela permet de ne recenser que la distribution de la partition sans s’occuper des autres systèmes.

Ensuite, on revient sur la distribution principale et on fait un update-grub. On apprécie alors sa légèreté (quelques Ko, au-dessus de 100Ko, c’est que le problème décrit commence à se profiler ou qu’il y a beaucoup de noyaux qui traînent). Au boot suivant, l’apparition du menu grub est instantanée.

Original post of alterlibriste.Votez pour ce billet sur Planet Libre.

À force de les rencontrer sur des événements libristes comme les RMLL et POSS, nous avons demandé aux ambassadeurs français d’OpenSuse de nous parler de leur distribution GNU/Linux.

Salut ! Présentez-vous. Comment justifiez-vous votre existence ?

Nicolas : Je viens d’un monde pur Windows. Un jour j’ai dû monter un petit serveur web où je devais installer une version Linux de mon choix sans rien y connaître. J’ai trouvé un tuto openSUSE 10.3 expliquant comment installer un serveur Apache + PhP en deux clics avec Yast-HTTP et je suis tombé dedans. Ensuite j’ai voulu tester sur mon PC pour virer mon Windows XP LSD (si, si…). J’ai commencé en 2005 avec un dual boot pour terminer exclusivement sous openSUSE depuis 2008. J’ai pris part à la communauté, puis à la création de l’association loi 1901 en 2012 en tant que secrétaire. L’an dernier j’ai repris le flambeau en devenant président.

Formaliser une association pour la promotion d’openSUSE en France était une nécessité pour faciliter la présence des membres et ambassadeurs openSUSE aux salons. Ils étaient reconnus par le programme openSUSE international mais pas forcément légitimes vis-à-vis des organisateurs locaux. On a un système d’adhésion qui couvre le budget hébergement. Quant aux goodies en version française et les clés USB, on vend à prix coûtant pour autofinancer les rééditions. Une année on était en galère mais on a eu la chance d’avoir du sponsoring de SUSE France qui nous soutient quand ils le peuvent, que ce soit financièrement ou matériellement au travers de goodies, etc. C’est appréciable de reproduire dans l’hexagone la synergie entre la communauté opensource et l’entreprise.

Antoine : openSUSE est la première distribution que j’ai utilisée. Je l’ai découverte en 2008, dans un magazine Linux. Des amis à moi utilisaient Ubuntu et m’avait convaincu d’essayer mais je n’avais trouvé que ce magazine, avec un DVD d’openSUSE (10.3) à l’intérieur. J’ai accroché : le changement, le vert, le caméléon comme logo. Bref, je l’ai installée (dual-boot), cassée, réinstallée, recassée, etc. J’ai appris plein de trucs, notamment grâce au forum Alionet. J’ai depuis essayé d’autres distributions, « en dur » mais aussi dans des machines virtuelles. Au final, je reviens toujours vers openSUSE, parce que c’est là où je me sens le mieux.

J’ai commencé à écrire des news sur Alionet en 2014, après la mort de jluce, un des admins du site qui en écrivait plein. Je trouvais dommage de ne pas essayer de continuer ce qu’il avait commencé. J’écris des articles sur openSUSE, pour informer de l’actualité du projet ; parfois des tutos, notamment quand je vois plusieurs personnes ayant une même difficulté sur le forum ; et enfin, sur tout ce qui touche au libre en général.

Qu’est-ce qui différencie openSUSE des autres distros ?

À mon sens, c’est une distribution qui s’adresse aussi bien aux débutants qu’aux utilisateurs avancés (powerusers) avec un certain nombre de qualités :

• La distribution répond aussi bien à des besoins de poste de travail, d’ordinateur portable ou encore de serveur (elle partage le même core SUSE Linux Entreprise Server). Je l’utilise sur mes propres serveurs qu’ils soient physiques ou virtualisés, mes stations de travail fixes ou portables. Quelle que soit l’utilisation, ce qu’appréciera l’utilisateur, c’est sa stabilité. D’ailleurs, il existe également des images ARM pour les Raspberry Pi, Pi2 et Pi3.
• L’ensemble des environnements graphiques proposés ont le même degré de finition et d’intégration dans la distribution que ce soit sur l’ISO de base : KDE (défaut), GNOME (mon bureau par défaut), LXQt, XFCE mais aussi via les dépôts en ligne pour MATE ou Cinnamon ou encore Enlightenment.
• L’outil d’administration Yast est un atout indéniable pour administrer la machine que ce soit les dépôts en ligne, l’ajout/suppression de logiciel, la gestion des services, des utilisateurs, etc. De nombreux modules sont disponibles et de nouveaux arrivent régulièrement pour suivre les évolutions technologiques comme Snapper pour gérer les instantanés (snapshots) du système de fichiers Btrfs ou encore celui pour gérer des conteneurs Dockers.
• Pour les utilisateurs débutants il est possible d’installer via Yast un serveur web, FTP ou email en quelques clics. Idéal pour avoir une base fonctionnelle et ensuite « mettre les mains dedans ». D’ailleurs l’édition manuelle, n’invalide pas l’utilisation de YaST dans la majorité des cas.
• Si l’utilisateur avancé ne veut pas utiliser Yast, il est tout à fait en droit d’éditer les fichiers de configurations manuellement et d’utiliser Zypper pour la gestion des paquets (un équivalent robuste de apt-get des familles DEB). Les administrateurs systèmes apprécieront également le dernier projet né : Machinery, un outil pour GNU/Linux afin d’inspecter les configurations des machines.
• Ce que j’apprécie justement dans la communauté openSUSE c’est que les outils ne sont pas élitistes et profitent également aux autres distributions. Prenons par exemple l’outil OpenBuildService (OBS) qui est une forge utilisée pour construire des packages. L’instance publique utilisée pour les différentes versions d’openSUSE (et de SLES) est ouverte aux contributions, actuellement l’openSUSE Build Service héberge 47 593 projets, pour un total de 402 280 paquets dans 77 223 dépôts et est utilisée par 45 616 personnes. Il est simple et ouvert à tous de se créer un compte et packager sur cette plate-forme sans pour autant se limiter à *SUSE seulement, ni aux plates-formes Intel. Votre paquet peut-être construit pour toutes les distributions majeures (RHEL, CentOS, Fedora, SLES, openSUSE, Debian, Ubuntu, Mageia, AchLinux, etc) avec le support matériel allant des processeurs ARM jusqu’au mainframe. D’ailleurs le projet VLC utilise sa propre instance de l’OBS pour packager l’ensemble des versions du célèbre logiciel. L’instance privée permettant également la construction de logiciels pour les plateformes Windows.

Pourquoi est-elle moins connue en France qu’en Allemagne ?

Elle n’est pas populaire qu’en Allemagne, de nombreux pays l’utilisent et ce n’est pas pour rien qu’elle est souvent entre la troisième et cinquième place sur DistroWatch.

En revanche, c’est indéniable, elle reste méconnue en France. Je pense qu’il y a plusieurs raisons à cela.

D’une part, c’était une distribution payante à la base, elle n’est devenue gratuite sous l’appellation openSUSE qu’à partir la version 10.

Quand j’ai démarré Linux en 2004, j’ai commencé avec Ubuntu car j’avais des problèmes de reconnaissance de matériel, ce qui s’est clairement amélioré par la suite. À présent, je ne rencontre plus de difficulté de support matériel que ce soit sur de l’assemblé ou du constructeur même si bien évidemment, je me documente avant d’acheter. Un autre manque était le nombre de logiciels disponibles mais là encore la communauté a largement rattrapé son retard.

Ensuite, il y a eu le « scandale » des accords Novell Microsoft alors que Novell possédait SUSE. Paradoxalement, même si tout le monde a crucifié la distribution, c’est cette collaboration qui a permis à l’ensemble des distributions Linux de s’insérer sur un réseau géré en active directory 100 % Windows. Comme je me fais souvent troller sur les stands avec cela, je tiens d’ailleurs à préciser que suite au rachat de Novell par Microfocus, SUSE et Novell sont deux entités distinctes et les accords liaient spécifiquement Novell et Microsoft, SUSE n’est donc plus concerné.

Pour toutes ces raisons, je pense que la communauté francophone est en retrait par rapport aux autres mais dès que l’on franchit les frontières de l’Hexagone, ce n’est plus la même répartition. C’est d’autant plus frustrant que lors d’événements du type RMLL, Solutions Linux, Paris OpenSource Summit, Capitole du Libre, des personnes viennent nous revoir d’une année à l’autre en nous disant qu’elles ne regrettent pas d’avoir essayé notre caméléon. Elles n’ont pas eu besoin de venir sur le forum chercher de l’aide. Comme toujours, les personnes qui s’inscrivent ont généralement des problèmes à résoudre, il manque les autres pour qui tout s’est bien passé.

En tout cas c’est moins facile d’avoir de l’aide… Moi aussi, je me suis battu avec une carte réseau récalcitrante et j’ai laissé tomber. Dommage, j’aimais bien. Comment on fait quand on galère ?

La communauté openSUSE francophone est clairement moins importante que celles d’autres distributions. C’est l’histoire de l’œuf ou la poule : est-ce que la communauté est petite à cause de sa popularité dans l’Hexagone ou est-ce l’inverse ?

Il existe néanmoins des moyens de trouver de l’aide sur openSUSE :

• La mailing liste francophone
• IRC #openSUSE-fr sur Freenode
• le forum Alionet.org

Bref, un éventail de plate-formes pour essayer de correspondre à chacun.

Vous avez tout le temps plein de goodies. Il y a des sous dans openSUSE ? Quel est le modèle économique ?

openSUSE est financée en majeure partie par SUSE, qui a lancé la distribution. L’entreprise encourage ses ingénieurs à participer à openSUSE. Du coup ils peuvent bosser sur la distribution sur une partie de leur temps de travail. Il y a aussi d’autres entreprises qui font des dons de matériel (notamment les machines pour l’openSUSE Build Service).

Concernant les goodies, lorsqu’on est ambassadeur openSUSE, il est possible via le wiki + email de prétendre à un kit stand. Il faut indiquer l’événement, le volume de personnes attendues, etc. openSUSE envoie alors un kit stand que nous devons redistribuer gratuitement. (nappe, 2 t-shirts, flyers en anglais).

En parallèle l’association Alionet a pris plusieurs initiatives :

• Prendre contact avec SUSE France avec qui nous avons d’excellents contacts pour quelques goodies supplémentaires.
• Éditer sur le budget de l’association propre des t-shirts et clés USB car nous n’en avions pas de la part de nos partenaires.
• Nous prenons en charge l’impression de documents en français puisque openSUSE ne fournit que des informations en anglais.

Pourquoi est-elle passée en rolling release ?

En fait, elle n’est pas passée en rolling release. ;-)

Le projet propose maintenant deux distributions : une « classique », openSUSE Leap, la distribution principale, l’héritière de l’openSUSE que l’on connaissait jusqu’à l’an dernier. La dénomination Leap souligne le fait qu’il y a eu un changement dans la façon de construire la distribution, en faisant une base commune avec SUSE Linux Enterprise (SLE) la distribution commerciale de SUSE. Un « saut » qui s’est traduit également dans le numéro de version : 13.2 -> 42.1.

Une en rolling release effectivement : openSUSE Tumbleweed (« virevoltant » en anglais). Elle, c’est l’héritière de « Factory », une base de code instable qui servait aux contributeurs du projet à mettre au point openSUSE ancienne formule (avant Leap). Cette base de code a évolué, s’est dotée de nouveaux outils pour finalement être considérée comme « stable » – dans le sens où ça ne casse pas, mais bien sûr ça bouge vite – et être appelée Tumbleweed.

Pourquoi faire ça ? Pour mieux répondre aux besoins de chacun : ceux qui ont besoin d’une grande stabilité ou ne veulent pas beaucoup de changements sur leur système peuvent utiliser Leap, ceux qui veulent des logiciels toujours plus récents (mais stables ; pas des préversions ou très peu) peuvent utiliser Tumbleweed.

Quoi de neuf dans la nouvelle version, justement ?

Une des nouvelles les plus intéressantes est l’arrivée de Plasma 5.8.1, la toute dernière version du bureau KDE. C’est une version estampillée LTS, c’est-à-dire que KDE va se focaliser sur la stabilité et la durée pour cette version, ce qui colle avec les objectifs de Leap. Pour la petite histoire, openSUSE et KDE se sont mis d’accord pour que leurs calendriers respectifs collent et que Leap 42.2 puisse intégrer dans de bonnes conditions cette nouvelle version de Plasma. Et pour la deuxième petite histoire : KDE chez openSUSE, c’est entièrement géré par la communauté (ça ne vient pas de SLE).

Pour les amateurs de cartes et d’embarqué, de nouveaux portages pour ARM sont disponibles.

Pour les amateurs de nouveaux systèmes de fichiers : Snapper peut utiliser les quotas Btrfs pour gérer le nettoyage des snapshots.

Vous trouverez plus d’infos dans l’annonce de version.

La communauté Fedora se rend compte d’un déclin de l’intérêt des gens pour les principales distributions. Est-ce aussi un constat sur openSUSE ?

Pas à ma connaissance. Il y a peut être eu des signes en amont qui expliqueraient pourquoi openSUSE a revu son mode de fonctionnement en proposant deux versions : Leap et son rapprochement avec la version SUSE Linux Entreprise et la rolling release Tumbleweed face à la popularité d’Archlinux par exemple.

Ce que je constate en revanche, c’est le déclin de communauté d’entraide en général. La montée des réseaux sociaux a tué les bons vieux forums d’entraide et les mentalités ont changé. On peine à recruter des bonnes volontés mais ce n’est pas un problème exclusif à Alionet.

Comment peut-on aider au développement d’openSUSE ?

Une petite liste non-exhaustive de choses que l’on peut faire pour participer :

• En parler à ses amis/ses collègues/son LUG pour mieux faire connaître les distribs ;
• Participer au forum, salons IRC, entraide avec les autres utilisateurs ;
• Traduction : une nouvelle plate-forme est maintenant utilisée pour traduire openSUSE : Weblate. Tout le monde peut y participer.
• Contribuer au wiki (Alionet a aussi son propre wiki « historique » sur Linuxpédia) ;
• Construire/maintenir des paquets : sur l’openSUSE Build Service  ;
• Rapporter/Corriger des bugs : sur le bugzilla ;
• Proposer de nouvelles fonctionnalités ;
• Participer au support de cartes ARM ;
• Ajouter des tests à openQA ;
• Demander, on trouvera quelque chose à vous faire faire ^^

Le mot de la fin est pour vous

openSUSE est un projet global vraiment passionnant avec une communauté internationale très ouverte. Sa communauté francophone bien que peu nombreuse n’en est pas moins réactive et les personnes ont toujours trouvé des réponses à leurs questions.

N’hésitez pas à tester cette distribution et à venir à notre rencontre. :)

Pour aller plus loin :

• Le site de la communauté francophone OpenSuse
• Le site francophone d’openSUSE

Original post of Framablog.Votez pour ce billet sur Planet Libre.

Original post of genma.Votez pour ce billet sur Planet Libre.