Journal [Tutoriel] Installer Adélie Linux à la main (comme un gU4u)

Posté par  (site Web personnel) . Licence CC By‑SA.
Étiquettes :
19
10
mar.
2021

Sommaire

Salut Nal, tu te rappelles peut-être les mésaventures de mon neveu s'initiant à Python 3 malgré Windows 10. On me suggérait alors de le passer de force sous Linux, solution directe et couillue comme il se doit sur LinuxFR.

Hé ben voilà, ça y est, le pas est franchi. 'Fin, en quelque sorte. On lui a fait installer VirtualBox et Ubuntu en classe. Pour découvrir.
Il en est très content : il n'a plus de place, plus de mémoire et sa souris saute en permanence. Le fait qu'il ait dû attribuer 8 Go de RAM & 40 Go d'espace disque* à la VM sur sa machine de l'Education Nâle y est peut-être pour quelque chose.
(*: chiffres non contractuels)

- Bah alors Nini, tu as au moins découvert comment ça marche, Linux ?
- Bah oui, bien sûr ! J'ai cliqué sur "Suivant" -> "Suivant", puis pour installer Python je suis allé sur le "Snap Store".

Mon mug m'échappa des mains. Tu comprendras Nal, que la situation était critique. Je devais immédiatement lui installer Adélie Linux.

- Mais Tonton, pourquoi Adélie ?
- C'est un Linux léger basé sur musl-C et le gestionnaire de paquets APK (comme Alpine). Il ne se salit pas les mains, n'utilise pas systemd et expédie les firmwares proprios sur un dépôt externe ; Il est donc éthiquement pur, comme Greta Thunberg et BHL.
- Mais il a au moins un avantage sur Alpine ?
- Bien sûr ! Il est ouvert au desktop, ce qui veut dire qu'on y trouve Firefox, VLC et, pour toi mon fripounet, un client Torrent. Ah et il supporte de vieilles architectures comme le Pentium MMX ou PowerPC (Mac G3 et +).

Partitionnement

Je lui laisse utiliser un LiveCD GParted et partitionner à la souris, car je veux qu'il ait une vision graphique du disque.

On crée 3 partitions : /boot (500 Mo) en ext2 , swap (512 Mo) en linux-swap, / (le reste) en ext4.

gparted

Installation depuis le LiveCD Adélie

Clavier & APK

On télécharge la dernière ISO sans installeur. Ça va le dissuader de cliquer sur Suivant ;).

Une fois live-logué en root avec un clavier QWERTY, on passe en français avec :

# loadkeys /usr/share/keymaps/i386/azerty/fr-latin9.map.gz

On monte nos 2 partitions extfs dans la racine éphémère /target/ :

# mount /dev/sda3 /target
# mkdir /target/boot
# mount /dev/sda1 /target/boot

On y initialise le gestionnaire de paquets APK :

# mkdir -p /target/etc/apk
# cp /etc/apk/repositories /target/etc/apk/
# cp -r /etc/apk/keys/ /target/etc/apk/

Juste avant de découvrir le dépôt Adélie, il va nous falloir une connexion Internet :

# dhcpcd eth0 &
# apk --root /target --initdb add
# apk --root /target update

apk

Paquets de base

On installe successivement la base du système (filesystem+Bash+OpenRC/Service_réseau_NetIfrc+client_DHCP), le noyau Linux, et le chargeur de démarrage GRUB :

# apk --root /target add adelie-base bash-binsh ssmtp sysvinit openrc netifrc netifrc-doc dhcpcd 
# apk --root /target add easy-kernel easy-kernel-modules
# apk --root /target add grub grub-bios

Configuration de base

On renseigne les ultimes fichiers de config avant le chroot :

# cp -p /etc/shells /target/etc/
# cp -p /etc/resolv.conf /target/etc/
# echo 'adelie10' > /target/etc/hostname
# sed -i s/$/' adelie10'/ /target/etc/hosts
# cp -PRr /target/usr/share/openrc/runlevels/ /target/etc/

Chroot et configuration finale

On effectue un chroot :

# mount -B /dev /target/dev
# mount -t proc none /target/proc
# mount -t sysfs none /target/sys
# chroot /target

a) On inscrit GRUB sur le secteur de démarrage (MBR) :

# mkdir /boot/grub
# grub-mkconfig -o /boot/grub/grub.cfg
# grub-install --boot-directory=/boot /dev/sda

b) On active le compte root :

# passwd root

c) On paramètre un service "keymaps" qui passera le clavier en français (via l'outil loadkeys utilisé ci-dessus) :

# apk add gzip kbd-keymaps
# sed -i 's/keymap="us"/keymap="fr-latin9"/' /etc/conf.d/keymaps
# rc-update add keymaps default

d) On paramètre un service "net.eth0" qui attribuera une IP à la carte réseau (via l'outil dhcpcd utilisé ci-dessus) :

# echo 'config_eth0="dhcp"' > /etc/conf.d/net
# cp /etc/init.d/net.lo /etc/init.d/net.eth0
# rc-update add net.eth0 default

d) On paramètre un service "udev" qui détectera le matériel et chargera les pilotes (via l'outil modprobe) :

# rc-update add udev boot
# rc-update add udev-trigger boot

Finalement, avant de redémarrer au bouton, on écrit la définition de nos partitions :

# vi /etc/fstab

fstab

Premier démarrage

Outils indispensables

On installe successivement des outils matériels (fsck.ext2, lspci, lsusb, alsactl, ip, ping, dig, iptables), des commandes shell (clear, which), des outils système et des outils de compression :

# apk add hdparm parted e2fsprogs pciutils usbutils alsa-utils ethtool iproute2 iputils traceroute bind-tools curl ufw
# apk add ncurses debianutils-which tree
# apk add lsof htop nano vim strace
# apk add bzip2 lzip xz zip unzip

Pour pouvoir copier des fichiers depuis Windows avec WinSCP, on lance un serveur SSH :

# apk add openssh
# rc-update add sshd default
# service sshd start

Serveur d'affichage X11

En guise de système d'affichage, on va installer cette vieille carne dépassée de X11/Xorg. Oh, on pourrait être plus moderne en utilisant Wayland, mais le seul compositeur présent est celui de KDE, ce qui ne convient pas exactement à notre micro-machine.

# apk add xorg-server

Vu qu'on utilise udev (plus précisément eudev), notre pilote clavier/souris sera forcément evdev :

# apk add xf86-input-evdev

Notre pilote graphique pourrait être intel/ati/nouveau (NVIDIA), mais on est ici sous VirtualBox :

# apk add xf86-video-vboxvideo

On installe une série d'utilitaires X11 (le dernier contenant le fameux startx), un gestionnaire de fenêtres (le léger IceWM), deux outils IHM (le gestionnaire de fichiers PCManFm, Firefox) :

# apk add setxkbmap xsetroot xrandr xdpyinfo xlsclients xlsfonts xauth xhost xcalc xclock xedit xeyes xmag xmessage xdotool xterm xkill xinit
# apk add icewm
# apk add pcmanfm firefox-esr

On ajoute une section de configuration pour le clavier français (qui fera l'équivalent de setxkbmap fr à chaque lancement) :

# vim /etc/X11/xorg.conf.d/10-setxkbmap.conf

x11_kbd

Finalement, on configure l'init de X11 pour lancer IceWM à la place de KDE (qui n'était de toute façon pas installé) :

# vim /etc/X11/xinit/xinitrc

x11_wm

Le moment est venu de se lancer :

# startx

x11_gui

Conclusion

On constate un espace disque occupé d'~800 Mo, et encore ~200/512 Mo de RAM libre avec Firefox et plusieurs applications lancées.

  • # Ext4 plus rapide qu'Ext2

    Posté par  . Évalué à 3.

    Je suis en pleine installation d'un serveur de travail pour ma copine et moi. Ma nature étant de me poser des questions avant, j'ai fait des comparaisons ce matin entre les systèmes de fichiers. Ma conclusion (inattendue) c'est que Ext4 est plus rapide que Ext2, et que Ext4 s'en sort premier ou second dans toutes les situations. Ça va d'ailleurs encore s'améliorer avec les «fast-commits», mais il faudra reformater le système de fichier pour en bénéficier dans quelques semaines.

    Il ne s'agit que de Benchmarks, mais si tu veux jeter un oeil :

    • [^] # Re: Ext4 plus rapide qu'Ext2

      Posté par  (site Web personnel) . Évalué à 1. Dernière modification le 10/03/21 à 15:15.

      Je te remercie pour les liens !

      La raison pour laquelle Adélie recommande ext2 sur la partition /boot (alors que / est bien en ext4), serait que le FS aurait moins d'overhead et serait pris en charge par plus d'outils en cas de dépannage. J'ai donc suivi sans rien toucher…
      (À noter que si c'est le critère, à ce moment, autant la mettre en vfat ;) )

      Après ils sont nombreux à dire comme toi ; je la mettrai en ext4 la prochaine fois, y a pas de raison que ça ne marche pas !

      • [^] # Re: Ext4 plus rapide qu'Ext2

        Posté par  . Évalué à 4. Dernière modification le 10/03/21 à 15:39.

        Il faut faire attention que ça change souvent. En 2012 c'était moins évident. Sur le serveur le noyau est ancien, donc je prend des benchmarks datés de 5 ans. En plus je veux grapiller dans la Ram, alors un système de fichier en moins c'est un module de moins.

        Il y a eu récemment des changements dans XFS et des progrès dans F2FS qui les font passer devant Ext4. Mais bien sûr il faut ramener à son usage : un bench sur 1000 fichiers à servir ne concerne pas mon cas ni celui de ton neveu.

    • [^] # Re: Ext4 plus rapide qu'Ext2

      Posté par  (site Web personnel) . Évalué à 2.

      J'ai depuis réinstallé 2 VMs en mettant /boot en ext4, et cela marche effectivement très bien !

  • # informations manquantes

    Posté par  . Évalué à 2.

    On constate un espace disque occupé d'~800 Mo, et encore ~200/512 Mo de RAM libre avec Firefox et plusieurs applications lancées.

    Pour combien de Ram en tout ? et sur quels sites, avec combien d'onglets ?

    512 Mo de swap, c'est un peu casse-gueule à moins d'avoir vraiment beaucoup de Ram, non ?

    • [^] # Re: informations manquantes

      Posté par  (site Web personnel) . Évalué à 1.

      Pour combien de Ram en tout ? et sur quels sites, avec combien d'onglets ?

      Sur 512 Mo (c'est ça le /512 ;) ). Un seul onglet bien sûr, comme sur la capture, je n'envisage même pas d'en ouvrir 3 avec moins de 1 Go de RAM !

      512 Mo de swap, c'est un peu casse-gueule à moins d'avoir vraiment beaucoup de Ram, non ?

      Techniquement tu n'as pas tort, et justement on en a peu ; mais comme on veut faire petit, je réduis la partoche swap au minimum (= taille RAM).
      Un solution plus souple serait de mettre le swap dans un fichier (comme Windows), ce qui sauverait le maximum d'espace en permettant au swap de grossir à volonté.

      • [^] # Re: informations manquantes

        Posté par  . Évalué à 4.

        Tu veux relancer la polémique de l'autre journal ? :-)

        Sérieusement, Firefox peut consommer beaucoup plus que ça sur des sites comme celui de La Poste. Tu devais prévoir 4 fois plus. Et avec si peu de Ram, les navigateurs Midori, Web ou Falkon consomment moins.

        • [^] # Re: informations manquantes

          Posté par  (site Web personnel) . Évalué à 2.

          Tu veux relancer la polémique de l'autre journal ? :-)

          Balance, c'est où :-p ?

          Et avec si peu de Ram, les navigateurs Midori, Web ou Falkon consomment moins.

          Alors nonobstant le fait qu'il s'agisse d'une VM de classe-labo qui n'aura pas de tel usage,
          et considérant qu'effectivement, des gens pourraient avoir envie de l'installer sur un ordinosaure (qui est un usage fréquent d'Adélie),
          Tu as raison sur le swap, et pour le reste il faut noter que seuls Firefox et Chromium sont actuellement packagés/disponibles sur Adélie. Il n'y a donc pas vraiment encore de navigateur léger à dispo.

          Bon quoique :

          # apk add links
          

          ;)

      • [^] # Re: informations manquantes

        Posté par  (site Web personnel) . Évalué à 2. Dernière modification le 10/03/21 à 18:27.

        Un solution plus souple serait de mettre le swap dans un fichier

        La dernière "grosse" régression du kernel qui mangeait littéralement le contenu de tes disques durs était lié à l'utilisation d'un swap sous la forme d'un fichier, il me semble que Linus lui même a dit que c'était pas bien de faire ça, c'était utilisé très marginalement de cette façon et que ça n'aurait pas du être permis à la base. J'ai lu ça quelque part, j'aurais tendance à pas utiliser de swap en fichier depuis que j'ai lu ça (bon en vrai je ne mets même plus de swap depuis plusieurs années sur mes machines, juste un earlyoom pour tuer les process qui mangent trop de RAM avant que l'OS ne soit sous pression).

        • [^] # Re: informations manquantes

          Posté par  . Évalué à 7.

          La dernière "grosse" régression du kernel qui mangeait littéralement le contenu de tes disques durs était lié à l'utilisation d'un swap sous la forme d'un fichier

          C'est inexact : c'était un bug dans une Releate Candidate, pré-version réservée aux développeurs et qui est justement là pour trouver les bugs. À ma connaissance aucun noyau n'est jamais officiellement sorti avec un bug aussi grave (et je surveille la chose depuis fort longtemps).

          • [^] # Re: informations manquantes

            Posté par  (site Web personnel) . Évalué à 1.

            Hé orfenor, ça marche ;) !!!

          • [^] # Re: informations manquantes

            Posté par  (site Web personnel) . Évalué à 2.

            Alors c'est vrai, mais ils ont quand même eu de la chance que ce soit détecté par les benchmarks de Phoronix et des infras automatisées qui accidentellement utilisait le swap sous forme de fichier :)

            • [^] # Re: informations manquantes

              Posté par  . Évalué à 5.

              De la chance ? je ne suis pas d'accord. La détection rapide montre que les tests sont faits, or c'est le but d'une RC. Il y a déjà eu des bugs assez chauds dans les RC.

              • [^] # Re: informations manquantes

                Posté par  . Évalué à 2.

                Je suis pas sur que le fait qu’un bug aussi critique ait été découvert dans une RC, je suppose en flinguant la machine d’un développeur/testeur, soit quelque chose dont il faut être fier.

                Si le but avait découvert par de l’intégration continue avant le merge, y’aurait de quoi fanfaronner. Mais ironiquement, le but même de la CI c’est précisément d’éviter d’avoir à faire ce genre d’annonces, et donc ça pete vachement moins d’envoyer un e-mail à une liste aussi grosse en disant juste « un bug critique a été découvert et corrigé pendant le cycle de development ».

                Linuxfr, le portail francais du logiciel libre et du neo nazisme.

                • [^] # Re: informations manquantes

                  Posté par  . Évalué à 3.

                  Eh ? t'as vu la taille du noyau ? tu veux écrire la centaine de milliers de tests nécessaires ? Et vu le temps de compilation, pas sûr que l'intégration continue soit utilisable.

                  • [^] # Re: informations manquantes

                    Posté par  . Évalué à 2. Dernière modification le 12/03/21 à 02:57.

                    J’ai pas dit que c’était facile. Le temps de compilation est pas pire que pas mal d’autres projets qui ont clairement des tests. Et je doute que ça soit le plus gros problème à résoudre pour etre honnête.

                    Après, oui, c’est un boulot titanesque, mais faut bien commencer un jour. Tout comme le boulot pour écrire le noyau, et l’amener au niveau ou il est, était titanesque. Personne n’a protesté que c’était trop de boulot et a laissé tombé.

                    (Et c’est plutôt de plusieurs millions pour un projet de cette taille)

                    Linuxfr, le portail francais du logiciel libre et du neo nazisme.

              • [^] # Re: informations manquantes

                Posté par  (site Web personnel) . Évalué à 3.

                La détection rapide montre que les tests sont faits

                Et bien dans ce cas concret, ce ne sont pas des tests qui l'ont trouvé, mais des benchmarks sur Phoronix (mine de rien, il trouve des régressions souvent) c'est plus une détection par accident qu'un vrai résultat de test car le but ultime de ces benchs est de mesurer la performance, le fait qu'un build de test de perfs (mais pas tous) utilise un fichier de swap plutôt qu'une partition ou pas de swap ici semblait purement accidentel, d'après l'auteur. Je persiste à dire qu'ici, c'est vraiment de la chance que ça ait été trouvé avant que ça aille plus loin. D'ailleurs le fait que ça ait été trouvé sur la dernières RC montre bien que ça aurait pu passer inaperçu très facilement.

        • [^] # Re: informations manquantes

          Posté par  (site Web personnel) . Évalué à 0. Dernière modification le 10/03/21 à 22:22.

          il me semble que Linus lui même a dit que c'était pas bien de faire ça, c'était utilisé très marginalement de cette façon et que ça n'aurait pas du être permis à la base.

          Ces gens-là auraient donc tort ? Parce que sur le reste, ils calculent à peu près comme nous ;).

          • [^] # Re: informations manquantes

            Posté par  (site Web personnel) . Évalué à 3. Dernière modification le 11/03/21 à 13:12.

            Quel rapport ? pagefile.sys ce n'est pas la swap de linux, même si la fonctionnalité est la même, la techno et les paradigmes de l'OS sont eux bien différents. Je suis désolé, mais je dois dé-pertinenter ton commentaire.

            (PS je ne disais pas qu'utiliser de la swap est marginal, mais le fait de ne pas la mettre sur sa propre partition).

            • [^] # Re: informations manquantes

              Posté par  (site Web personnel) . Évalué à 4.

              Je ne pertinenterai donc pas le tien :) !
              Linus a peut-être une bonne raison de ne pas vouloir de fichier swap, et c'est peut-être justifié par l'implémentation ; mais présenté comme ça, rien ne permet de l'affirmer.
              Si c'est juste une opposition de principe ou de tradition, on a le droit de l'ignorer.

  • # Et si on voulait faire tourner ça dans virtualbox avec les additions invités ?

    Posté par  . Évalué à 3.

    … j'ai peur aqu'il manque bcp de dépendances, non ? :D

    • [^] # Re: Et si on voulait faire tourner ça dans virtualbox avec les additions invités ?

      Posté par  . Évalué à 3.

      C'était une vraie question.

      Je cherche l'image la plus légère pour un hpyerviseur capable de lancer une VM pouvant lire de la video en profitant des accélarations matérielles.

      Je n'ai pas de contraintes sur l'hyperviseur - même si virtualbox me semble le plus approprié (hyper-v ou qemu ca me convient)

      Par contre le plus léger pour compiler les drivers guest c'est 4Go. descendre à 2 je kifferais.

      Un conseil sur ce point ? :D

  • # musl

    Posté par  (site Web personnel) . Évalué à 7.

    C'est marrant que personne ne rebondisse sur musl comme libc, qui est aussi le choix d'Alpine. Il me semble (d'après nos équipes d'admin) que c'est probablement pas un bon choix, même pour faire du "léger". La glibc est sûrement (beaucoup, beaucoup) plus grosse en taille brute, mais aussi probablement (beaucoup, beaucoup) plus rapide à l'exécution, même sur des vielles archis, au vu de sa maturité, de l’obsession perpétuelle des gros acteurs (Intel, Redhat, et plein d'autres) de vouloir en tirer les meilleures performances possibles. De plus, musl a été (est peut-être encore) il y a finalement pas si longtemps que ça, la source de 90% des bugs de sécurité de 90% des images docker du monde (qui pour beaucoup utilise musl pour gagner en taille, au détriment de la performance et de la sécurité), lié au fait que c'était encore (bon c'est relatif quand même ceci dit) un projet relativement "jeune" et beaucoup moins utilisé, donc moins bien maintenu.

    • [^] # Re: musl

      Posté par  . Évalué à 4.

      Si tu as des liens qui étayent tes propos, je serais intéressé.

      • [^] # Re: musl

        Posté par  (site Web personnel) . Évalué à 2. Dernière modification le 11/03/21 à 13:06.

        Oui c'est vrai, ça manque de documentation, déjà tu peux essayer de manger ça: http://www.etalabs.net/compare_libcs.html

        D'ailleurs, de ce que je vois, l'aspect performance ne semble plus être vrai à l'heure actuelle, musl à des résultats qui semblent très proches de la glibc.

        Je ne sais pas si c'est représentatif, mais on peut rechercher les CVE pour la sécurité: http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=musl vs http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=glibc avec encore une fois un résultat qui me contredit. Mais c'est à prendre avec des pincettes pour deux raisons:

        • l'engouement pour musl est relativement récent comparé à la durée de vie du projet glibc,
        • ensuite il faudrait comparer par gravité / type de CVE,
        • il faut garder en tête que musl il y a peu était encore beaucoup moins utilisé que glibc, moins de trous trouvés ne veut pas dire moins de trous tout court.

        Ensuite, je ne fait que reporter sûrement avec beaucoup d'imprécisions ce que d'autres m'ont dit (enfin, des gens en qui j'ai confiance et qui font de l'infra).

        EDIT: Ah et j'aime beaucoup exagérer, quand je dis "90% du temps" il faut entendre "parfois" :)

        • [^] # Re: musl

          Posté par  . Évalué à 3.

          Le test d'Étalab est fait par le concepteur de musl, sur le site de musl il dit bien que ce n'est pas à jour.

          Pour le reste tu as raison sur les trous potentiels. Mais sur les avis «des autres», on est assez conservateur en tant que sysadmins, et je crois qu'on se justifie comme on peut, c'est humain.

          Tu vas finir par croire que je te contredis exprès ;-)

          • [^] # Re: musl

            Posté par  (site Web personnel) . Évalué à 2. Dernière modification le 11/03/21 à 13:26.

            Ah ah non, mais le débat sur musl on en trouve un peu des bouts partout, reddit, forums de gentoo, et autres. Souvent des benchmarks passent sur des sites tiers aussi, c'est un débat intéressant en vrai, je ne faisais que synthétiser ce que j'en avais agrégé dans les deux trois coins de l'internet de mon boulot ou j'en ai entendu des bout :) Je le répète encore, je peux me vautrer grave sur le sujet, alors tes contradictions sont les bienvenues.

    • [^] # Re: musl

      Posté par  (site Web personnel) . Évalué à 2. Dernière modification le 11/03/21 à 13:04.

      Sur ce lien https://www.etalabs.net/compare_libcs.html il semblerait que niveau performance elle s'en sorte pas si mal.

      • [^] # Re: musl

        Posté par  (site Web personnel) . Évalué à 2.

        Oui tout à fait, ça semble très différent de la dernière fois que je l'ai consulté, mais musl a eu le temps de mûrir ces dernières années !

      • [^] # Re: musl

        Posté par  (site Web personnel) . Évalué à 2.

        Tiens j'avais pas fait gaffe:

        All of these figures were obtained using my libc-bench suite, in UTF-8 locales, on one particular Intel Atom N280-based machine. They are not intended to be rigorous, only to give a rough idea of relative order-of-magnitude performance.

        Ça me paraît assez bancale comme benchmark, la glibc contient beaucoup de code et optimisations qui sont spécifiques à certaines architectures, les résultats varieraient probablement beaucoup selon les machines.

    • [^] # Re: musl

      Posté par  (site Web personnel) . Évalué à 3.

      Je suis content que tu aies des réponses ; l'aspect sécurité est entièrement absent de mon cas d'usage, mais j'étais curieux tout de même (nous n'utilisons pas Alpine).

      • [^] # Re: musl

        Posté par  (site Web personnel) . Évalué à 4.

        A prendre avec des pincettes toujours, le projet musl est très actif et mes retours s'arrêtent à ceux que j'ai eu il y a deux ou trois ans. Je pense que c'est très probablement un projet très sérieux, et stable.

  • # Alerte !

    Posté par  . Évalué à 10.

    # vim /etc/X11/xinit/xinitrc
    # startx

    Infliger des trucs qui ont besoin de bidouiller xinitrc et utiliser startx en 2021 à des enfants, ça mériterait qu'on te dénonce aux services sociaux!!

    • [^] # Re: Alerte !

      Posté par  . Évalué à 6.

      Si c'est avec Emacs c'est la prison directe ?

      • [^] # Re: Alerte !

        Posté par  . Évalué à 10.

        Amputation d'un doigt.

        Avec Emacs, ça suffit à rendre le système totalement inutilisable.

        • [^] # Re: Alerte !

          Posté par  . Évalué à 4.

          • [^] # Re: Alerte !

            Posté par  . Évalué à 3.

            Tu es télépathe ? j'étais sur la même page hier soir !

          • [^] # Re: Alerte !

            Posté par  . Évalué à 5.

            C'est pour Vim.

            Ne confondons pas l'amélioration d'un excellent éditeur de texte avec une application conçue pour des hommes-pieuvres, voyons!

            • [^] # Re: Alerte !

              Posté par  . Évalué à 3. Dernière modification le 13/03/21 à 14:13.

              Excuse moi d'avoir présupposé le lecteur de linuxfr avait les compétence pour adapter un projet open-source/hardware à ses besoins ;)

          • [^] # Re: Alerte !

            Posté par  (site Web personnel) . Évalué à 2.

            Je continuer de recommander celui-là à tout débutant.

            (comment le reconnaître ? Tout se passait bien pour lui jusqu'à la fin de la 1ère section du tuto)

    • [^] # Re: Alerte !

      Posté par  (site Web personnel) . Évalué à 6. Dernière modification le 10/03/21 à 22:35.

      Tu préférais vraiment que j'explique comment installer KDE/Wayland, et paramétrer D-Bus/Polkit en mode utilisateur pour les relier à SDDM (après avoir défini des filtres d'UID/GID pour l'affichage des comptes) ?

      Parce que, à la fois pour démontrer la légèreté et la simplicité de Linux, ça se posait pas là ;).

      • [^] # Re: Alerte !

        Posté par  . Évalué à 5.

        Certes, mais au moins ce sont de vrais problèmes de 2021…

        • [^] # Re: Alerte !

          Posté par  (site Web personnel) . Évalué à 2.

          Je te charriais un peu hein ; avec Weston on peut avoir Wayland avec un terminal, l'heure, et Firefox. C'est même plus simple à installer, il n'est juste pas packagé sous Adélie (je vais peut-être le faire).

  • # La légèreté a la peau dure

    Posté par  . Évalué à 7. Dernière modification le 11/03/21 à 06:18.

    Plop Tarnyko<
    Vu l'accompagnement à l'installation et configuration, as tu déjà essayer la même chose avec une distro plus classique ?

    Il semble que la recherche de la légèreté soit toujours basée sur des éléments factuels d'il y a 10 ou 15 ans, aujourd'hui remisés dans la catégorie des croyances (Xfce est plus léger, …) Là, ok, avec ce bon vieux icewm le bureau est vraiment léger (en plus icewm permet de faire qq trucs qu'aucun autre permet) mais ajoutons à ça la remarque sur la lib musl, le confort général pour l'usager, et regardons ce qui se fait ailleurs.

    Ici un burlingue avec une conf faite en 10mn (et disposant de tous les zigouigouis clickodrome bluetooth, réseaux, et effets lampes magiques) :

    plasma

    muny@twitter.com

    • [^] # Re: La légèreté a la peau dure

      Posté par  (site Web personnel) . Évalué à 2. Dernière modification le 11/03/21 à 09:30.

      as tu déjà essayer la même chose avec une distro plus classique ?

      Touché ; les étapes "liveCD" fonctionnent sûrement aussi à partir d'Ubuntu (avec DPKG à la place d'APK). C'était aussi un prétexte pour montrer Adélie…

      Xfce est plus léger

      Oui, ce que les gens le croient avant de s'apercevoir qu'un GTK+2 chargé en permanence, ça bouffe pas mal. Et en plus les applis sont rachitiques !

      Ici un burlingue avec une conf faite en 10mn

      Intéressant. C'est quoi, LXQt ?

      • [^] # Re: La légèreté a la peau dure

        Posté par  . Évalué à 7. Dernière modification le 11/03/21 à 11:51.

        KDE Plasma

        ;-)

        L'astuce ? ne pas installer akonadi & sa clique. Si l'arbre des dépendances du KDE de ta distro est bien propre sur lui, ça passe crème (parceque KDE n'en a nul besoin pour parfaitement fonctionner)

        muny@twitter.com

        • [^] # Re: La légèreté a la peau dure

          Posté par  (site Web personnel) . Évalué à 5. Dernière modification le 12/03/21 à 05:24.

          Je viens de réussir à le faire tourner.
          Effectivement, Wayland/Plasma + Firefox, ça ne consomme pas beaucoup plus qu'X11/IceWM + Firefox (des pouillèmes). Et ça ne tire pas Akonadi !
          Par contre le "menu Démarrer" freeze plusieurs secondes à chaque action, c'est assez agaçant ; j'ai l'impression ça pourrait être dû au fondu enchaîné, mais n'ai pas trouvé où le désactiver.

          Les étapes sont plus complexes, nécessitent de créer un utilisateur limité et lancer 2 services :

          Installer le nécessaire côté client :

          # apk add ttf-liberation  # (police de caractères TTF)
          # apk add qt5-qtwayland   # (rajoute le support wayland/wayland-egl)
          # apk add konsole
          

          Installer le serveur KWin/KWayland :

          # apk add mesa-dri
          # apk add kwin
          

          Paramétrer D-Bus/elogind pour fournir les interfaces D-Bus libinput :

          # rc-update add dbus default
          # rc-update add elogind boot
          # reboot
          

          Se logger en tant qu'utilisateur limité et vérifier :

          $ loginctl
          _SESSION  UID    USER  SEAT TTY
                c1 1000 tarnyko seat0 tty1_
          

          Lancer KWin :

          WAYLAND_DEBUG=1 XDG_RUNTIME_DIR=$HOME dbus-launch kwin_wayland --drm --xwayland
          

          À partir d'un autre TTY, même utilisateur, lancer Konsole :

          QT_QPA_PLATFORM=wayland XDG_RUNTIME_DIR=$HOME konsole
          

          Voilà déjà le résultat sur le TTY d'origine, et pour installer/lancer Plasma :

          # apk add plasma-desktop
          $ QT_QPA_PLATFORM=wayland XDG_RUNTIME_DIR=$HOME dbus-launch plasmashell
          
    • [^] # Re: La légèreté a la peau dure

      Posté par  . Évalué à 4.

      (Xfce est plus léger, …)

      Si on parle de l'usage mémoire de Xfce lui-même, 70 Mo de mémoire utilisé au démarrage, c'est pas mal je trouve.

      Et puis plus léger que quoi ?

      Les applis sont rachitiques

      C'est le revers de la médaille.

      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Suivre le flux des commentaires

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