La distribution Linux Manjaro disponible en version 20.0

La distribution Linux Manjaro disponible en version 20.0

La distribution Linux Manjaro disponible en version 20.0

« Lysia », de son petit sobriquet, est disponible depuis peu au téléchargement sur son site officiel. Les améliorations sont nombreuses.

La variante par défaut de Manjaro est basée sur Xfce, embarquant la révision 4.14 de l’environnement. Manjaro 20.0 met l’accent sur la finition de l’interface, avec notamment un nouveau thème Matcha et un utilitaire pouvant stocker les différentes configurations d’écrans.

L’édition KDE est fournie avec Plasma 5.18, avec une interface personnalisée pour le système. Tous les thèmes Breath2 ont des versions claire et sombre, un écran de chargement animé, des profils Konsole, des thèmes Yakuake « et d’autres petits détails ».

L’édition GNOME récupère la version 3.36 de l’environnement avec toutes les améliorations de performances déjà repérées dans nos articles sur Ubuntu 20.04 et Fedora 32. En plus d’une révision du thème général, Manjaro dispose d’un fond d’écran dynamique (la teinte change selon l’heure, à la manière de macOS), zsh est le nouveau shell par défaut et les applications sont classées dans le menu.

Toutes ces versions sont basées sur un noyau Linux 5.6. Lysia gère également l’installation sur une partition ZFS. Le gestionnaire de paquets Pamac passe en mouture 9.4, apportant le support des snaps et flatpaks. 

Commentaires (16)


J’avais découvert cette distribution lors d’un stage de fin d’étude (il y a donc de cela quelques années maintenant <img data-src=" />) et j’avais vraiment adoré cette distribution ! En plus c’était la première fois que j’utilise une arch, seulement du Debian, Ubuntu et Turnkey avant ça.


«&nbsp;Le gestionnaire de paquets Pamac passe en mouture 9.4, apportant le support des snaps et flatpaks. »

→ ce qui est totalement inutile pour une distribution de type « rolling release », puisque la raison d’être des Snaps et autres Flatpaks est avant tout de fournir des dépendances plus à jour que celles disponibles au sein de distributions de type « fixed release », où elles restent bloquées sur des versions devenant rapidement obsolètes (les seuls correctifs de sécurité ne suffisent pas à compenser l’obsolescence technologique), ce qui est leur défaut inhérent. Si, il y a 10 ans, ce n’était pas encore un réel problème, le modèle « fixed » n’est hélas plus admissible (en dehors des serveurs ou autres systèmes qui se doivent évidemment de rester sur des bases stables dans le temps) pour les PC de M. et Mme Toutlemonde (cibles de distributions comme Manjaro), qui doivent au contraire rester le plus à jour possible.


C’est pas inutile ça évite aux développeurs de devoir faire une version Archlinux/Manjaro de leur appli. Donc ça a ses avantages en terme de distribution des logiciels.



Après, je partage ton avis sur Flatpak/Snap que je n’utilise absolument pas et qui m’inquiète beaucoup en terme de sécurité et d’intégration.


Toujours pas de version qui s’appelle “Killy”… je suis déçu.








127.0.0.1 a écrit :



Toujours pas de version qui s’appelle “Killy”… je suis déçu.





<img data-src=" />T’as de la chance que la police ait des choses plus importantes à faire ; tu peux te retrouver en prison pour des blagues comme ça.



Et puisque Inpact Hardware s’attarde beaucoup sur Ubuntu sur Raspberry, Manjaro dispose également d’une distribution desktop pour rasberry pi 4, qui, à mes yeux, fonctionne mieux que la version Ubuntu server “desktopisée” … et beaucoup plus sympa que Raspbian pour un bureau léger ;-)



https://manjaro.org/download/arm/raspberry-pi-4/arm8-raspberry-pi-4-xfce/



&nbsp;


En fait on a parlé de Manjaro en même temps qu’Ubuntu, il y a six mois (notamment pour détailler le mode OEM qui est assez pratique). Mais comme ça n’a pas trop changé depuis (contrairement à Ubuntu, qui supporte d’ailleurs depuis le RPi 2 désormais), on en a pas trop reparlé depuis :&nbsp;



https://www.inpact-hardware.com/article/982/comment-installer-manjaro-arm-sur-ra…


C’est la première distri avec un noyau 5.6 donc un wireguard en mode kernel ?

Si c’est le cas <img data-src=" />



PS : enfin c’est ptet pas le genre de distro à installer sur un serveur


Si quelqu’un sait pourquoi une fresh install de Manjaro 20 ne boot pas en VM Hyper-V Gen2, je suis preneur :p



Je ne parle pas du Xorg qui ne démarre pas, post-boot du LiveCD, je parle bien d’une install qui finit sans erreur avec leur assistant mais qui ne boot pas ensuite (ne passe pas le splashscreen Hyper-V).

C’est comme si le bootloader était mal/pas installé, c’est étrange. SecureBoot est désactivé.



Je n’ai aucun souci lors de l’install d’une fresh Arch…


Pour un updatomaniac comme moi, le seul problème d’une distribution en rolling release, c’est que les nouvelles versions majeures ne changent rien :(








Obidoub a écrit :



C’est pas inutile ça évite aux développeurs de devoir faire une version Archlinux/Manjaro de leur appli. Donc ça a ses avantages en terme de distribution des logiciels.



Heu… Tu connais le principe des PKGBUILD ? À la limite, y a pas besoin de faire « une version Arch/Manjaro » de l’appli : tu crées juste un fichier texte avec les instructions nécessaires pour compiler, dont un lien vers le code source, et c’est bon. Il restera juste à passer un coup de « makepkg -s » et tu l’auras, ton paquet installable sous ces distros.







Tr4ks a écrit :



C’est la première distri avec un noyau 5.6 donc un wireguard en mode kernel ?



Non : Manjaro est une dérivée d’Arch. C’est donc cette dernière qui est la première à proposer des MAJ qui seront ensuite disponibles sur Manjaro (qui a sa propre politique en la matière, laquelle consiste à ne fournir les MAJ qu’en lots plusieurs fois par mois, alors que c’est dès que ça arrive sur Arch).

De plus, Manjaro n’utilise par défaut que le dernier noyau LTS en date : pour passer au noyau normal ou d’autres noyaux LTS encore maintenus (voire un noyau temps réel), il faut le demander soi-même depuis le Gestionnaire de paramètres de Manjaro (à ne pas confondre avec celui propre à l’environnement de bureau choisi : ce sont deux outils distincts).









Trit’ a écrit :



Heu… Tu connais le principe des PKGBUILD ? À la limite, y a pas besoin de faire « une version Arch/Manjaro » de l’appli : tu crées juste un fichier texte avec les instructions nécessaires pour compiler, dont un lien vers le code source, et c’est bon. Il restera juste à passer un coup de « makepkg -s » et tu l’auras, ton paquet installable sous ces distros.





Oui je connais et il faut bien trouver un lutin pour créer ce PKGBUILD, le maintenir, répondre aux plaintes des utilisateurs quand ça marche pas, l’adapter quand le processus de build est modifié, etc.



Celui qui développe son logiciel n’a pas forcément envie de se taper la maintenance d’un RPM, DEB, PKGBUILD, port, snap, flatpak…









Tr4ks a écrit :



C’est la première distri avec un noyau 5.6 donc un wireguard en mode kernel ?

Si c’est le cas <img data-src=" />







Fedora 31 et 32 disposent d’un noyau 5.6.7









Trit’ a écrit :



« Le gestionnaire de paquets Pamac passe en mouture 9.4, apportant le support des snaps et flatpaks. »

→ ce qui est totalement inutile pour une distribution de type « rolling release », puisque la raison d’être des Snaps et autres Flatpaks est avant tout de fournir des dépendances plus à jour que celles disponibles au sein de distributions de type « fixed release »







Pour les dépendances, ça fonctionne dans les deux sens. Aussi bien pour une application récente qui a besoin des dernières technos à la mode, qu’une vieille appli basée sur des technos archaïques, mais que t’as peut être besoin de continuer à utiliser, pour x raisons.



Ensuite, limiter les Flatpak à cette seule histoire de dépendances, c’est passer à côté d’autres fonctionnalités intéressantes :







  • une meilleure sécurité, puisque les applications sont exécutées dans une sandbox

  • une gestion plus fine des droits. Avec le modèle traditionnel, c’est tout ou rien. Là, tu peux accorder ou non, à chaque application, un accès à certains périphériques (micro, webcam…), à la géolocalisation…

  • la possibilité d’installer facilement plusieurs versions d’une même application en parallèle (par exemple, la version stable et la version de développement)

  • les développeurs peuvent fournir eux-mêmes leur application telle qu’ils l’ont voulu (certaines distributions désactivant certaines fonctionnalités pour ne pas enfreindre des brevets logiciels, par exemple)

  • les applications seront exécutées à l’identique chez les développeurs et chez les utilisateurs, facilitant la reproductibilité de bugs et donc leur correction











Trit’ a écrit :



&nbsp;(en dehors des serveurs ou autres systèmes qui se doivent évidemment de rester sur des bases stables dans le temps) pour les PC de M. et Mme Toutlemonde (cibles de distributions comme Manjaro), qui doivent au contraire rester le plus à jour possible.





Pour moi justement un serveur est l’exemple-type de machine qui doit rester le plus a jour possible, à cause des impératifs de sécurité (surtout si il est exposé sur le net, mais même si il ne l’est pas, en cas de faille il pourrait se retrouvé touché par d’autres machines infectées qui viendrait l’attaquer).



Les PC de M. tout-le-monde aussi, pour les mêmes raisons.



Les seules machines pour moi qui peuvent rester bloqués sur d’anciennes version de soft ou d’OS c’est les machines qui n’interagissent pas avec l’extérieur : Pilotage de machines industrielles ou test, stations de prod graphique non raccordé au réseau de l’entreprise (pour des tâches spécifiques),…



Un serveur n’utilisant pas les dernières versions des softs ne veut pas dire qu’il n’est pas à jour en terme de sécurité. Les update de sécurité sont disponibles durant toute la durée du support (je pense 3 ans chez debian et 5 chez ubuntu LTS).


Fermer