Journal Un mois avec Clear Linux

Posté par  . Licence CC By‑SA.
Étiquettes :
21
5
avr.
2021

Sommaire

J'ai commencé à découvrir Linux avec Fedora, puis j'ai basculé brièvement sur Debian pour finalement terminer sur Ubuntu et je n'ai pas changé depuis des années. Je me sers essentiellement de mes PCs Linux pour développer et aller sur internet.

Ayant un vieux portable datant de 2012 et tournant avec un processeur Intel (i5-2540M), je me suis dit que je j'allais le réinstaller avec Clear Linux pour profiter des avantages de cette distribution et voir un peu quelque chose de différent.

Pour ceux qui ne connaissent pas, Clear Linux (https://clearlinux.org/) est une distribution Linux proposée par Intel. Elle se démarque des autres distributions par le fait qu'elle est optimisée pour une architecture x86 et revendique donc des performances accrues.

Phoronix a fait un test et vous pouvez trouver les résultats ici: https://www.phoronix.com/scan.php?page=article&item=fedora-ubuntu-clear2020&num=1

En résumé, Clear Linux est plus rapide pour de nombreuses taches que Fedora 33 ou Ubuntu 20.10. La différence peut parfois atteindre les 10%, voir plus.

Evidemment et comme tous comparatifs, il faut prendre ces résultats avec des pincettes, mais néanmoins il témoigne d'un effort de la part d'Intel de fournir une distribution qui tire le meilleur de ses processeurs et de son expertise.

Clear Linux peut donc donner éventuellement une deuxième jeunesse à un vieux PC, et cela même si Intel destine cette distribution à des fins professionnelles (IT, DevOps, Cloud, AI).

Particularité

Stateless

Clear Linux est une distribution stateless. L'idée, entre autres et pour ce que j'en ai compris, est de séparer les données utilisateur, les données systèmes et les fichiers de configuration.

En gros ça veut dire quoi? Que les fichiers dans /etc, /opt, /home, /var, /usr/local sont gérés par l'utilisateur, ceux dans /usr sont gérés par le système. Et donc, par exemple, si vous voulez configurer ssh pour changer le port sur lequel ssh écoute, vous ne trouverez pas de fichier ssh_config dans /etc/ssh/ puisque le système n'installe rien (ou presque) dans les répertoires utilisateurs. Ce sera donc à vous de le créer. Vous pouvez trouver des exemples dans les dossiers /usr/share/[defaults|doc].

Un des avantages est que l'on peut revenir à un distribution fraîchement installé en supprimant les répertoires /etc et /var.

Rolling release

Clear Linux est mis a jour régulièrement. On se retrouve donc avec des versions récentes de toutes les applications. Si je compare mon Ubuntu 20.04 et ma Clear Linux 34460, gcc est en version 9.3.0 contre 10.2.1 respectivement.

Gestion des paquets

C'est la que le plus gros changement pour l'utilisateur a lieu. Pour ceux qui sont habitués à apt et à sa richesse de paquets, la différence est grande. Clear Linux utilise swupd à la place de apt. Il n'y a pas de différences fondamentales dans le principe d'utilisation sauf que le nombre de paquets est plus réduit. Par exemple, si vous voulez installer Putty ou Typora, vous ne pourrez pas et vous allez devoir faire autrement.

Et faire autrement veut dire utiliser flatpack ou compiler les sources (pour l'instant je ne l'ai fait qu'une fois).

Au final si on n'arrive pas à installer un paquet avec swupd, une recherche sous google avec "nom_du_paquet Clear Linux" donne rapidement une page expliquant comment installer ce paquet (ex: https://clearlinux.org/software/flathub/visual-studio-code).

L'installation

J'ai eu quelques soucis pour installer Clear Linux sur mon portable mais c'était du à un mauvais support de UEFI par le BIOS sur ce vieux portable.

L'installation est simple et rapide quand elle marche. Une fois l'image copiée sur une clef USB et après avoir booté sur cette clef en mode UEFI, on se retrouve avec un Live Clear Linux qui permet soit de tester le système, soit de l'installer.

A l'utilisation

Dans mon cas particulier, Je me sers de ce portable pour du développement Python ou C avec Eclipse, Visual Code et Code Composer Studio.

Clear Linux tourne avec Gnome (v3.38). Il y a sûrement mieux mais franchement ca marche. Le seul défaut que je lui trouve est qu'il faut faire 2 manipulations pour changer d'application: une pour afficher le choix des applications et un clic pour sélectionner la nouvelle application. Je suis sur que ça se configure mais j'ai la flemme de le faire pour l'instant. Gnome est aussi un peu tristounet.

Le démarrage et l'extinction sont super rapides.

Je n'ai pas encore eu de plantage alors que j'en ai (pas souvent mais) régulièrement sur Ubuntu.

Par contre j'ai quelques problèmes graphiques avec Firefox que je n'ai pas encore réussi à résoudre. Quand je change d'onglet, l'affichage n'est pas toujours rafraîchi. Donc je me retrouve dans mon nouveau onglet avec le contenu de l'onglet précédent.

Je n'ai pas encore eu de redémarrage demandé contrairement à Ubuntu.

La doc est bien faite et on trouve facilement ce que l'on veut. Le support de la communauté est aussi appréciable.

Du point de vue gestion mémoire je trouve que Clear Linux fait bien son boulot. Juste après m'être identifié, Clear Linux consomme environ 800MB alors que mon Ubuntu 18.04 est déjà à 1.6GB. Les deux systèmes n'étant pas des installations fraîches, c'est difficile de comparer mais néanmoins j'ai le sentiment subjectif que mon Clear Linux est moins gourmand en mémoire. Il faudrait faire de vrais tests pour confirmer ce sentiment.

Et la vitesse?

Difficile à dire mais ça marche bien c'est sur. Ce portable était plutôt du haut de gamme d'il y a presque 10 ans (un HP8560w) et franchement, à part le poids et l'épaisseur qui font leur age, ce portable est capable de faire tourner a peu près n'importe quoi encore aujourd'hui. (Pour info j'ai changé par le passé le SSD par un SSD plus récent mais d'entrée de gamme et rajouté 8Go de mémoire pour un total de 12Go).

Si j'ai le temps, et comme il me reste un ssd vierge dans un coin, il faudrait que je teste la compilation de quelque chose de gros avec un Clear Linux et une Ubuntu, ou que je compare le temps de démarrage.

Au final

Je la garde et même si tout n'est pas parfait, je trouve que Clear Linux se démarque des autres distributions en proposant une philosophie différente et une optimisation qui me semble aide à lutter contre une obsolescence rapide du matériel informatique.

Si je dois la comparer avec Ubuntu, Clear Linux est moins destiné au grand public que ne peut l'être Ubuntu. Avec Clear Linux il faut être prêt à résoudre des problèmes que l'on n'aurait pas eu si on avait installé Ubuntu.

  • # putty & linux-tkg

    Posté par  . Évalué à 5 (+3/-0).

    putty sous linux, vraiment ?

    Sinon, je crois qu'une bonne partie des performances de clearlinux est attribuée à certains patches qui sont entre-autres optimisations inclus dans le noyau non officiel linux-tkg que l'on peut installer sur la plupart des distros. Il serait intéressant de voir un bench entre une arch/fedora/ubuntu avec ce kernel et la clearlinux.

    • [^] # Re: putty & linux-tkg

      Posté par  . Évalué à 5 (+3/-0).

      Putty ne sert pas qu'à établir des connexions SSH, et il a l'intérêt de permettre de paramétrer ses profils de configuration via une GUI et de pouvoir les sauvegarder.

      Je l'utilise pas mal pour les connexions séries, chaque équipement ayant ses propres subtilités de fonctionnement pas forcément très bien documenté.

      Emacs le fait depuis 30 ans.

      • [^] # Re: putty & linux-tkg

        Posté par  . Évalué à 4 (+2/-0).

        De la même manière que tu peux configurer plusieurs conf pour minicom ou garder des aliases pour cu…

        • [^] # Re: putty & linux-tkg

          Posté par  . Évalué à 2 (+1/-0).

          De la même manière, tu peux produire un ELF avec xxd.
          (Bon. Ok, là je troll)

          Chaque outil à son public / contexte d'utilisation :)

        • [^] # Re: putty & linux-tkg

          Posté par  . Évalué à 2 (+0/-0).

          Tiens, il y a des gens qui arrivent à utiliser minicom? Surprenant… quand j'ai dû interagir avec des ports série, j'ai trouvé microcom nettement plus facile à utiliser, et pourtant, c'est un outil des plus primitifs, et pour cause, il s'agit d'un des applets de busybox.
          Configurer minicom, c'est un sacré bordel. Microcom impose de passer les options en ligne de commande, certes, mais au moins il n'essaie pas de modifier des trucs dans /etc par défaut. Quitte à utiliser un outil moins austère, clairement je privilégierai putty à minicom.

          Au cas où, les raisons pour lesquelles je n'ai pas utilisé putty sous linux sont, dans l'ordre:

          1) je n'y ai pas pensé, tellement à faire l'amalgame "putty == client ssh pour windows"… je continue parce que les autres raisons auraient été valables, si j'y avais pensé:
          2) microcom (comme minicom) permets d'intervenir via une liaison ssh, depuis un headless
          3) utiliser microcom avec un outil comme chat ou expect est plus simple, vu que c'est pas graphique

    • [^] # Re: putty & linux-tkg

      Posté par  . Évalué à 1 (+1/-0).

      Putty sous Linux parce que j'ai l'habitude de l'utiliser pour mes ports séries. J'essayerai minicom si jamais Putty ne me convient plus.

      Je n'ai pas trouvé de comparatif de linux-tkg avec Clear Linux. Par contre (mais c'est un peu vieux) Phoronix avait essayé de reproduire certaines optimisations de Clear Linux sous Ubuntu et de comparer. En gros, avec des optimisations Ubuntu se rapproche de plus en plus de Clear Linux.
      https://www.phoronix.com/scan.php?page=article&item=ubuntu1810-fast-clear&num=1

  • # Compilateur utilisé & séparation libre-non-libre

    Posté par  . Évalué à 4 (+2/-0).

    L’approche « stateless » parait particulièrement intéressante, et l’idée que des efforts soient faits pour que le code soit exécuté le plus efficacement possible me plaît beaucoup (bon, pour le coup j’utilise un processeur Intel, mais je ne voudrais pas m’enfermer dans une marque voire une architecture matérielle spécifique, donc je ne suis pas certain qu’une distribution dont l’objectif est de cibler des processeurs particuliers ça soit faite pour moi – après je suppose que rien n’empêche de faire un build pour d’autres processeurs si la distribution devenait populaire). Un autre bon point, ça a l’air d’être ouvert à la contribution, et le caractère open source est mis en avant.

    Deux questions m’ont tout de suite traversé l’esprit en découvrant avec ce journal qu’il y avait une distribution Linux optimisée pour les processeurs Intel :

    • Quel est le compilateur utilisé pour construire les paquets ? Intel a son propre compilateur, ICC, non-libre, censé produire du code plus efficace pour ses propres processeurs. Clear Linux semble utiliser GCC, d’ailleurs la première chose qu’on peut voir sur le site est une actualité sur GCC et la deuxième chose, un article dans lequel on découvre qu’un des auteurs a écrit un patch pour GCC. J’imagine également qu’il est difficile de se passer de GCC pour construire une distribution entière et qu’utiliser deux compilateurs différents pourrait ne pas valoir la peine. Il n’y a cependant pas de confirmation formelle sur le site.
    • Est-ce qu’il y a une séparation stricte libre / non-libre dans les dépôts comme sur Debian, openSUSE ou Fedora ?
    • [^] # Re: Compilateur utilisé & séparation libre-non-libre

      Posté par  . Évalué à 2 (+2/-0).

      Au final, Clear Linux semble aussi fonctionner de façon efficace sur AMD.
      Phoronix a testé Clear Linux sur un AMD Rizen 3.
      https://www.phoronix.com/scan.php?page=article&item=clear-linux-zen3&num=6
      Et au final, Clear Linux est environ 15% plus rapide que les autres distributions.

      Pour les autres questions, je n'ai pas la réponse.

      • [^] # Re: Compilateur utilisé & séparation libre-non-libre

        Posté par  . Évalué à 1 (+0/-0). Dernière modification le 05/04/21 à 19:18.

        En fait, on oublie que AMD ou Intel, c'est la même chose, x86, que l'un ou l'autre optimise ses processeurs de leur côté ne change pas grand chose (d'un point de vue compilation j'entends bien sûr)…

        • [^] # Re: Compilateur utilisé & séparation libre-non-libre

          Posté par  . Évalué à 2 (+0/-0). Dernière modification le 05/04/21 à 21:04.

          Il y a un gros socle commun, mais il clairement des différences entre les modèles. En utilisant les options qui ciblent du matériel spécifique, tu rends ton programme potentiellement incompatible avec les modèles précédents ou concurrents parce que ce matériel n'aura pas nécessairement les instructions que ces options génèrent.

          Ou tout simplement, des optimisations qui rendent le code rapide / efficace pour ce modèle ne le sont pas forcément, voire causent des ralentissements sur un autre (en théorie possible, je ne sais pas si ça arrive en vrai).

          Après, il existe des détections de fonctionnalités à l'exécution, c'est ce que font pas mal les compilateurs Just In Time avancés il me semble (JavaScript, Java (?)). C'est certainement possible avec des langages compilés, mais attention à la taille du code, un truc trop gros peut ne pas tenir dans le cache et le résultat est plus lent…

  • # dinosaurdinateur

    Posté par  . Évalué à 2 (+0/-0).

    Pour les très vieille machine (style dell inspiron 1501), c'est potentiellement aussi plus performant ou bien il y a une limite d'âge sur les processeurs concernés ?

    Surtout, ne pas tout prendre au sérieux !

  • # Lié au bloat?

    Posté par  . Évalué à 4 (+2/-0).

    Je me demande, ça ne serait pas tout simplement lié au bloat, qui a pu être supprimé?

    Par exemple, Debian à la (fâcheuse, pour mon usage à moi, bénéfique, compte tenu de leur ambition à l'universalité) tendance d'activer un maximum d'options lors de la compilation des paquets. Ce qui a causé de très, très gros problèmes de performances avec notamment la SDL: la plupart des programmes utilisant la SDL n'utilisent pas son support de DBus (je n'en connais aucun, en fait, mais je dis la plupart pour me garder une marge d'erreur…), mais SDL avait un bug bien sale lié à DBus qui bouffait la totalité du CPU pour que dalle, à flooder stdout/stderr (je me souviens plus) etc etc.
    Bug que j'ai résolu à l'époque en compilant moi-même la SDL (depuis le paquet source debian) en virant toutes les dépendances inutiles (pour moi, j'entend et j'insiste) au passage.

    J'ai appliqué la même chose sur un nombre réduit de paquets (mpv et mpd), le gain n'est pas super sensible (sur ma machine), certes, mais pas improbable qu'il existe bel et bien, malgré la faible échelle.

    Il ne faut pas oublier que chaque dépendance, surtout des bibliothèques partagées, aura un impact à minima au chargement (résolution des symboles, vérifications des dépendances, voire tout simplement plus de données à lire depuis le disque dur!) et une distro qui installe moins de choses sera très probablement plus rapide.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.