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.
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
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
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
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
Le moment est venu de se lancer :
# startx
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 orfenor . É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 Tarnyko (site web personnel) . Évalué à 1. Dernière modification le 10 mars 2021 à 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 orfenor . Évalué à 4. Dernière modification le 10 mars 2021 à 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 Renault (site web personnel) . Évalué à 6.
Notons que maintenant le pilote ext4 du noyau prend en charge lui même ext3 et ext2.
[^] # Re: Ext4 plus rapide qu'Ext2
Posté par Tarnyko (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 orfenor . Évalué à 2.
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 Tarnyko (site web personnel) . Évalué à 1.
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 !
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 orfenor . É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 Tarnyko (site web personnel) . Évalué à 2.
Balance, c'est où :-p ?
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 :
;)
[^] # Re: informations manquantes
Posté par orfenor . Évalué à 4.
Tiens, fais-toi plaisir !
[^] # Re: informations manquantes
Posté par Christie Poutrelle (site web personnel) . Évalué à 2. Dernière modification le 10 mars 2021 à 18:27.
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 orfenor . Évalué à 7.
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 Tarnyko (site web personnel) . Évalué à 1.
Hé orfenor, ça marche ;) !!!
[^] # Re: informations manquantes
Posté par orfenor . Évalué à 3.
t'as mangé ton swap ?
[^] # Re: informations manquantes
Posté par Tarnyko (site web personnel) . Évalué à 3.
Mééé nan ! Tu causes de fichier swap sous Nunux, et ça remue ; comme devant ma porte quand je lâche du pain :).
[^] # Re: informations manquantes
Posté par Christie Poutrelle (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 orfenor . É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 groumly . É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 orfenor . É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 groumly . Évalué à 2. Dernière modification le 12 mars 2021 à 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 Christie Poutrelle (site web personnel) . Évalué à 3.
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 orfenor . Évalué à 3.
Bon bon bon. On va pas s'écharper hein ? «Deux contre un j'abandonne» (dit le Capitaine Haddock dans Le crabe aux pinces d'or).
[^] # Re: informations manquantes
Posté par Christie Poutrelle (site web personnel) . Évalué à 3.
C'était pas le but :)
[^] # Re: informations manquantes
Posté par Tarnyko (site web personnel) . Évalué à 0. Dernière modification le 10 mars 2021 à 22:22.
Ces gens-là auraient donc tort ? Parce que sur le reste, ils calculent à peu près comme nous ;).
[^] # Re: informations manquantes
Posté par Christie Poutrelle (site web personnel) . Évalué à 3. Dernière modification le 11 mars 2021 à 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 Tarnyko (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 Graveen . É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 Graveen . É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
[^] # Re: Et si on voulait faire tourner ça dans virtualbox avec les additions invités ?
Posté par Tarnyko (site web personnel) . Évalué à 2.
Ton message m'a incité à tenter mon premier empaquetage :).
On aurait pu faire plus simple pour commencer, mais j'apprends des trucs -plus sur VirtualBox que sur Adélie en fait. Checke la page de temps en temps, je posterai si j'arrive…
[^] # Re: Et si on voulait faire tourner ça dans virtualbox avec les additions invités ?
Posté par Tarnyko (site web personnel) . Évalué à 2.
OK c'est fait, premier paquet créé !
Le truc avec VirtualBox, c'est bien de mettre la carte graphique VBoxSVGA ; celle par défaut ne supporte pas le KMS et fait crasher l'affichage pendant l'init.
Pour installer :
Après tu peux tester les dossiers partagés, avec p.ex. cette commande adaptée à la capture :
Et pour tester l'accéléréation 3D :
(ça ne semble par contre pas suffisant pour Chromium, qui tourne pourtant sous VMware. Vu que la stack soft est la même, je dirais que c'est la carte 3D VBox qui PLM)
[^] # Re: Et si on voulait faire tourner ça dans virtualbox avec les additions invités ?
Posté par Tarnyko (site web personnel) . Évalué à 2. Dernière modification le 14 mars 2021 à 09:25.
Je me corrige moi-même, il faut plutôt faire :
Et ce sera d'ailleurs plus nécessaire quand j'aurai produit les paquets pour le partage de presse-papiers et le glisser-déposer, mais là je m'avance un peu :).
[^] # Re: Et si on voulait faire tourner ça dans virtualbox avec les additions invités ?
Posté par Tarnyko (site web personnel) . Évalué à 2.
J'ai finalement posté une version pré-finale des paquets (archis: pmmx/x86_64) sur la mailing list.
Ils sont plus complets que ce que je t'ai envoyé : il y a notamment le partage du presse-papiers et le glisser-déposer sous X11.
L'accel 3D ne marche pas (y a juste du swrast, concrètement ça bloque surtout Chromium), mais ça a l'air d'être le box général entre le noyau Linux, Wayland et le code VirtualBox.
J'attends un peu pour savoir si je dois améliorer !
# musl
Posté par Christie Poutrelle (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 Pierre-Alain TORET (Mastodon) . Évalué à 4.
Si tu as des liens qui étayent tes propos, je serais intéressé.
[^] # Re: musl
Posté par Christie Poutrelle (site web personnel) . Évalué à 2. Dernière modification le 11 mars 2021 à 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:
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 orfenor . É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 Christie Poutrelle (site web personnel) . Évalué à 2. Dernière modification le 11 mars 2021 à 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 Pierre Tramal (site web personnel) . Évalué à 2. Dernière modification le 11 mars 2021 à 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 Christie Poutrelle (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 Christie Poutrelle (site web personnel) . Évalué à 2.
Tiens j'avais pas fait gaffe:
Ç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 Tarnyko (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 Christie Poutrelle (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 Maclag . Évalué à 10.
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 orfenor . Évalué à 6.
Si c'est avec Emacs c'est la prison directe ?
[^] # Re: Alerte !
Posté par Maclag . Évalué à 10.
Amputation d'un doigt.
Avec Emacs, ça suffit à rendre le système totalement inutilisable.
[^] # Re: Alerte !
Posté par aiolos . Évalué à 4.
Faux :
https://github.com/alevchuk/vim-clutch
[^] # Re: Alerte !
Posté par orfenor . Évalué à 3.
Tu es télépathe ? j'étais sur la même page hier soir !
[^] # Re: Alerte !
Posté par Maclag . É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 aiolos . Évalué à 3. Dernière modification le 13 mars 2021 à 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 Tarnyko (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 Tarnyko (site web personnel) . Évalué à 6. Dernière modification le 10 mars 2021 à 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 Maclag . Évalué à 5.
Certes, mais au moins ce sont de vrais problèmes de 2021…
[^] # Re: Alerte !
Posté par Tarnyko (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 bubar🦥 (Mastodon) . Évalué à 7. Dernière modification le 11 mars 2021 à 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) :
[^] # Re: La légèreté a la peau dure
Posté par Tarnyko (site web personnel) . Évalué à 2. Dernière modification le 11 mars 2021 à 09:30.
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…
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 !
Intéressant. C'est quoi, LXQt ?
[^] # Re: La légèreté a la peau dure
Posté par bubar🦥 (Mastodon) . Évalué à 7. Dernière modification le 11 mars 2021 à 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)
[^] # Re: La légèreté a la peau dure
Posté par Tarnyko (site web personnel) . Évalué à 5. Dernière modification le 12 mars 2021 à 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 :
Installer le serveur KWin/KWayland :
Paramétrer D-Bus/elogind pour fournir les interfaces D-Bus libinput :
Se logger en tant qu'utilisateur limité et vérifier :
Lancer KWin :
À partir d'un autre TTY, même utilisateur, lancer Konsole :
Voilà déjà le résultat sur le TTY d'origine, et pour installer/lancer Plasma :
[^] # Re: La légèreté a la peau dure
Posté par xcomcmdr . Évalué à 4.
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 ?
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.