Sommaire
Ce journal évoque Arch Linux laquelle, étant une distrib rolling release, n' a pas de version qui sortirait et que je pourrai présenter. (Encore que le média d'installation connaisse une release mensuelle.)
Arch Linux est une distribution légère et rapide dont le concept est de rester la plus simple possible. Sa licence est GPL. Sa première version est de 2002 - elle a fêté ses 20 ans récemment. Elle a été créée par Judd Vinet, qui fut ensuite son leader, suivi de Aaron Griffin puis actuellement Levente Polyak . Ses mainteneurs sont bénévoles et Arch souhaite rester aussi "gratuite" que "libre". Seule l'architecture x86_64 est officiellement supportée.
Arch est une une distribution que l'on installe une fois puis qui n'a pas de version - souffrez une fois puis profitez ad vitam! (ou peut être : amusez vous une fois puis emmerdez vous!! bref) Elle permet d'utiliser les applications upstream peu après leur sortie et en outre le wiki - apparu en 2005- est apprécié de tous. Bien souvent, la clarté de ce wiki le rend utile aux utilisateurs d'autres distros. Greg Kroah-Hartman a d'ailleurs mentionné le fait qu'il utilise Arch et qu'il apprécie son wiki (décidément! entre ça, vim et GNOME, il a tout compris ! - fin du troll)
Et puisque je mentionne la relationne de la distribution au monde de Linux, logique de mentionner les distribs "filles" - comme Endeavour OS ou Manjaro, assez populaires si l'on se fie par exemple à distrowatch . Attention Manjaro possède cependant ses propres dépots - un peu comme Ubuntu vis à vis de Debian, et je ne vous la recommande pas. Tandis que Endeavour est essentiellement une manière d'installer Arch (avec certes quelques rares paquets en propre). Il existe une distrib pour ARM. On pourrait également citer le fait que Steam Deck tourne sur un fork de Arch pour profiter de la fréquence des maj - merci Arch!
Installation du système
https://wiki.archlinux.org/title/Installation_guide
Qui dit rolling release dit installer une fois pour de bon… Finis les upgrade semestriels!
L'idée de Arch est de laisser les utilisateurs apprendre en faisant par eux mêmes, plutôt que de proposer une install et une config toutes faites. À la base, en fonction de vos compétences, installer Arch peut sembler relever de l'aventure. Inutile de détailler les commandes ici, et inutile de vous diriger vers un blog aléatoire décrivant les manip - le wiki précise tout ce qu'il faut faire : après récupérer, vérifier puis booter sur une image il faut, en ligne de commande, se connecter au réseau, configurer le bon clavier, définir l'heure système, gérer les partitions, le boot loader puis redémarrer… Vous ne serez absolument pas guidé par l'OS et uniquement par le wiki : à vous de vous débrouiller un peu avec vos lignes de commande. Enfin un peu de fun! Bon ok s'il n'y a rien de sorcier, cela requiert de s'y connaître un minimum! Si les étapes sont très claires, je regrette qu'ils ne suggèrent pas un boot loader par défaut… pas évident pour nous commun des mortels de choisir! mais cela nous entraîne au point suivant.
Depuis 2021, cela a un peu évolué : le live inclut la possibilité d'utiliser un outil en mode texte qui va guider à travers ces étapes: archinstall, que je n'ai pas testé, et qui évolue progressivement. Et cette fois le boot loader est choisi pour vous : systemd-boot.
archinstall vous demandera aussi si vous voulez une interface graphique (KDE, GNOME, XFCE, Budgie, i3, Sway, etc). Donc si Arch elle même est en rolling et qu'il n'y a pas de sortie à décrire, il y a donc bel et bien des sorties : celles de archinstall. Vous pouvez par exemple voir une petite description ici ou encore là .
Au délà du mode texte, on peut noter l'existence d'un installeur graphique non officiel, ALG, qui se charge d'installer une Arch conforme à l'originale (les miroirs officiels sont configurés, la conf de pacman reste standard). Ce média permet donc de visualiser un bureau avant de l'installer, ce qui est parfois sympa pour s'assurer du support du matériel sans avoir à lire 1000 pages de forum en priant de ne rien avoir oublié… ALG utilise l'installeur Calamares, donc au lieu de définir où installer le système en mode texte, ce sera en mode graphique. En notant bien qu'il ne s'agit pas d'un composant officiel - et certains jugeront qu'on s'éloigne quelque peu de la philosophie de la distribution. Pour l'avoir testé, j'ai été agréablement surpris, même si des choses comme Anaconda me paraissent plus avancées.
Installation de soft et mise à jour
Bon maintenant que Arch est là, il va falloir ajouter des applis! Pour cela, il faut distinguer les paquets binaires de Arch - de grande qualité -, des non moins populaires dépôts AUR.
Dépôts binaires
Les paquets dans les dépôts officiels s'installent avec pacman, le gestionnaire de paquets de Arch. Sur un usage basique rien de très différent pour l'utilisateur d'un gestionnaire de paquets type red hat ou debian.
Arch essaie de garder autant que possible les applications telles que upstream - plus que Debian par exemple. De plus vous aurez tendance à trouver les dernières versions, dès que dispo upstream.
Il y a plusieurs dépôts comme on a souvent l'habitude chez d'autres distro : pour présenter les principaux, les paquets maintenus par les équipes officielles ("core" et "extra"), mais aussi le dépôt venant de contributeurs tiers et ayant été bien notés par de nombreux users ("community").
Arch ne demande pas particulièrement d'effort au quotidien mais, pour bien faire, Il y a des news à suivre, qui vont vous signaler si un paquet particulier demande une maintenance manuelle de votre part. Par exemple au moment où j'écris ce journal, je peux lire qu'il y a des choses par rapport à Pipe Wire et concrètement pour l'utilisateur
Si vous n’utilisez pas actuellement PipeWire pour l’audio et que wireplumber est installé sur votre système, veuillez réinstaller pipewire-media-session et redémarrer pour restaurer la fonctionnalité audio
Rien de dramatique, mais effectivement mieux vaut prévenir que passer des heures sur des forums! Là je lis la version fr des nouvelles visibles en première page sur https://archlinux.fr/ . Bien sûr un flux rss est utilisable. Il n'y a pas non plus cinquante avertissements - la news que je mentionne est du 24 mai, la précédente du 27 mars…
Dépôt AUR
AUR, ce ne sont pas des binaires, mais des recettes de cuisine (PKGBUILD) : vous récupérez la recette et compilez vous même le paquets (en général en utilisant un outil qui sait gérer les AUR).
L'avantage de AUR c'est que, notamment grâce à de nombreux contributeurs, il y a beaucoup de choses à disposition, parfois pour des applis ou des versions très très jeunes.
À VOUS DE VÉRIFIER CE QUE VOUS FAITES. On ne le dira jamais assez puisque un contributeur mal intentionné peut très bien indiquer de compiler n'importe quoi ou encore un PKGBUILD erroné vous faire exécuter une commande erronée désastreuse à souhait.
Il existe des outils très efficaces pour installer ces AUR et les mettre à jour (attention certains furent recommandés et ne le sont plus, je vous laisse voir ). Dans tous les cas, répétons le, Arch vous recommande de lire les PKGBUILD de ce que vous installez.
Autres
Arch possède un système (Arch Build System, ABS) permettant de compiler des paquets. Voir ici
Bien sûr on peut également gérer flatpak, snap et appimage sur Arch comme sur les autres distributions. Oui certes avec Arch vous avez tendances à déjà disposer des dernières version des logiciels, mais il peut rester d'autres intérêts.
Hérésie : en ce moment j'installe de nouveaux paquets et procède aux mises à jour non pas en ligne de commande avec pacman mais en mode graphique avec "Logiciels", la logithèque GNOME, donc via packagekit - d'autres logithèques graphiques étant également dispo, sur le même principe. En cherchant bien vous trouvez certes, sur le wiki, un avertissement vous disant que bouh les interfaces graphiques c'est pas bien pour installer des trucs en tant que root (https://wiki.archlinux.fr/Pacman/Trucs_et_Astuces ). A vous de voir!
Composants
Arch se veut une distrib moderne. Par exemple elle utilise systemd dès 2012 (un peu comme OpenSuse, après Fedora mais bien avant d'autres), non sans provoquer la création d'un fork, Artix. Arch a fusionné /bin et /usr/bin en 2013, assez tôt - encore une fois, un peu après Fedora et plutôt avant les autres.
A l'install, seul un environnement ligne de commande est dispo donc beaucoup de choses sont installées par l'utilisateur lui même. Donc si nous regardons "base" nous trouverons peu de choses : base contient en gros le shell (bash), l'init (systemd), le gestionnaire de paquets (pacman), le système de fichiers, les rares commandes indispensables. Le minimum. Cela signifie que hormis des choix structurels comme ceux ci dessus concernant l'init et le système de fichiers, ce sera souvent à l'utilisateur de choisir quoi installer - je ne peux donc pas écrire que Arch utilise tel bootloader ou Wayland depuis x années ou Pipewire, c'est à vous d'installer. Mais ce choix fait, Arch proposera une version très fraîche du logiciel choisi.
Puisque je parle de bureau, si on regarde des distribs comme Fedora ou Debian, il va bien sûr être possible d'utiliser les mêmes composants environnements comme KDE ou GNOME ou un gestionnaire de fenêtres comme i3 ou sway. Arch est bien sûr sur GNOME 42 ou KDE 5.25.
Évidemment on trouvera les outils habituels pour développer et certains recommanderont Arch pour cela.
En dehors du bureau, on peut installer apache ou nginx ou caddy et nft, et faire son serveur web sous Arch. Je m'apprêtais à ne pas recommander cela lorssque j'ai trouvé sur le wiki le fait que archlinux.org, aur.archlinux.org et presque toute l'infra tourne elle même sous arch! Incroyable.
C'est peut être une conclusion qui nous est offerte là : le fait d'avoir une rolling release offrant des versions très jeunes de logiciels pourrait laisser anticiper que de nombreux soucis apparaissent tout le temps. À l'usage, pas du tout. Le fait de ne pas "patcher" les logiciels est de privilégier une mise à jour constante est peut être simplement adapté à l'informatique actuelle - ou peut être les mainteneurs de Arch sont t'ils des demi-dieux, - ou peut être les arch linuxiens ont juste de la chance.
# Arch <3
Posté par Nibel . Évalué à 10.
Beaucoup ne recommandent pas d'utiliser un serveur avec une distribution rolling-release. Pourtant j'ai moi aussi tous mes serveurs sous Arch depuis plus de 10 ans et ça n'a jamais cassé.
Ca demande un peu plus de maintenance régulière mais je ne serre pas les meules comme quand on fait un "apt-get dist-upgrade". Parce qu'on en fait pas.
Et surtout, j'ai accès aux dernières technos dans les dernières versions quasiment immédiatement. Besoin qui ne sera clairement pas partagé par la majorité.
Merci de le rappeler, je vois trop souvent que "Manjaro c'est Arch avec une IHM". Bah non, Manjaro c'est Manjaro avec ses propres dépôts, ses propres bugs etc… Le cycle de MAJ des paquets est plus lent que chez Arch en moyenne. C'est une bonne distro prête à l'emploi cela dit.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Arch <3
Posté par Christie Poutrelle (site web personnel) . Évalué à 8.
Tous mes services sont dans des containers pour ma part, pour m'affranchir complètement de l'OS. En ce moment l'hôte est une Ubuntu server, mais c'est clair que jamais je ne mettrais un service sur Arch Linux. Je suis développeur de métier, je fais beaucoup de PHP entre autres, et si je devais héberger n'importe lequel des produits que je développe sur une Arch, ça exploserait à chaque mise à jour qui met à jour PHP dans une version majeure !
[^] # Re: Arch <3
Posté par Christie Poutrelle (site web personnel) . Évalué à 3.
Je précise quand même, j'utilise Arch depuis plusieurs années, sur mon desktop perso et sur mon laptop de travail. Vu qu'on utilise des containers ou VM pour tous nos projets, le choix de la distribution n'est pas impactant pour mon travail.
[^] # Re: Arch <3
Posté par Liorel . Évalué à 4.
Après, c'est non recommandé, mais tu peux interdire certaines màj automatiques à pacman, quitte à les faire à la main. Si tu veux figer PHP, tu peux tout à fait le faire. Bon c'est sûr que ça réduit l'intérêt de la rolling release.
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: Arch <3
Posté par Nibel . Évalué à 3. Dernière modification le 08 juin 2022 à 16:53.
C'est pas propre à Arch ce que tu décris là, ça exploserait que tu fasses un upgrade sur un Debian/Ubuntu ou que tu mettes à jour ta Arch.
C'est d'ailleurs un des intérêts de la conteneurisation que de figer les versions des dépendances.
Je m'y suis toujours pas mis chez moi parce que je n'y trouve pas d'intérêt dans mes services. Ils évoluent tous au rythme des dépendances et si ça casse, je répare (mais je n'ai rien de critique aussi, point important à souligner). Ce qui permet à l'intégralité de mes services de fonctionner dans un environnement à jour d'aujourd'hui. Ca réduit un peu la dette technique sur la durée.
Mais je dockerise en environnement pro oui.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Arch <3
Posté par Christie Poutrelle (site web personnel) . Évalué à 3.
Debian/Ubuntu ne mettent jamais à jour une version majeure de PHP, je prends l'exemple de PHP mais il y a plein d'autre paquets figés par semver.
[^] # Re: Arch <3
Posté par Storm . Évalué à 1.
Ben sur une version donnée oui, mais quand tu fais le passage à une nouvelle version là tu peux avoir le changement de majeure.
[^] # Re: Arch <3
Posté par Christie Poutrelle (site web personnel) . Évalué à 8.
Oui, mais c'est bien ça le fond du sujet, avec Arch linux, il n'y pas de différence entre une mise à jour de maintenance, sécurité et bugfix, que tu peux allègrement automatiser quotidiennement sur ton serveur si tu le souhaite, et une mise à jour majeure. Tu n'as pas le choix, toute mise à jour est potentiellement majeure. N'ayant pas de contrôle sur ce comportement, maintenir un serveur avec une distribution en rolling release devient de facto un bombe à retardement.
[^] # Re: Arch <3
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 10.
Ça c’est un argument que je vois régulièrement de la part des amateurs d’Arch et que je ne comprends pas – ou plus exactement que je ne comprends plus.
En ce qui me concerne, je n’ai jamais eu de problème à la mise à jour de version d’une Debian depuis plus d’une décennie – y compris la mise à jour de Raspberry Pi OS, qui n’est pas officiellement supportée mais très bien décrite, il y a juste une pré-installation à faire et c’est deux paquets à installer et une config à modifier.
Pour Ubuntu, ça a merdé à une époque, mais ça fait plus de 5 ans que les mises à jour se passent sans aucun souci, qu’elles soient de version mineure en version mineure ou de LTS en LTS, desktop comme serveur.
Alors je ne sais pas : est-ce que j’ai de la chance ? Est-ce que c’est des restes de méfiance de vieux problèmes maintenant résolus – comme j’ai eu des problèmes avec une Arch toute cassée il y a plus de 10 ans maintenant ? Je m’interroge.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Arch <3
Posté par Nibel . Évalué à 4.
Comme ça fait une bonne décennie également que je n'ai pas essayé de faire du dist-upgrade, mon commentaire sur le sujet n'est sans doute plus vraiment d'actualité.
Mais ouais j'ai cassé des Ubuntu et des Debian avec un dist-upgrade. Je préparais toujours un iso bootable à côté pour réinstaller from scratch.
C'est le mélange casse sur les dist-upgrade et besoin de paquets frais qui m'ont fait migrer sous Arch à l'époque.
Donc oui, c'est sans doute une méfiance d'un vieux problème maintenant résolu. Mais comme je n'ai connu que ça, je suis naturellement biaisé.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Arch <3
Posté par gnumdk (site web personnel) . Évalué à 9.
Perso, j'ai jamais utilisé Ubuntu mais je n'ai jamais cassé une Debian avec une dist upgrade.
Même quand on m'a demandé dans un grand Ministère de faire une migration Debian 4 -> 5 -> 6 -> 7 -> 8 -> 9
Après, je suis pas fou, j'ai pas essayé Debian 4 -> 9 :)
ps: Arch: 💙 Debian: 💛 Fedora: 💜
[^] # Re: Arch <3
Posté par saltimbanque (site web personnel) . Évalué à 3.
Debian 4 à 9 c'est sympa oui
j'ai dû manquer de chance la dernière fois :)
la commande aptitude a indiqué une erreur que je n'ai pas eu le temps de lire, pouf ça a redémarré -> quelques heures de nettoyages au pifs avant de parvenir à retrouver un aptitude fonctionnel. Je ne me plains pas non plus, sur un upgrade tous les trois ans ça reste léger.
[^] # Re: Arch <3
Posté par gnumdk (site web personnel) . Évalué à 3.
Je n'ai jamais utilisé aptibug, peut être la raison.
[^] # Re: Arch <3
Posté par Zatalyz (site web personnel) . Évalué à 5.
Ça fait partie de mes grandes interrogations chaque fois que j'installe un serveur. En voyant les autres commentaires, je comprends un peu mieux pourquoi certains préfèrent des serveurs figés : pas de maj, pas de casse (jusqu'à ce que l'absence de mise à jour devienne un problème de sécurité). Mais pour avoir des serveurs en rolling release et d'autres où il faut faire les grosses upgrade, je trouve la rolling release sacrément plus confortable à l'usage. J'ai une préférence pour faire des mises à jour très régulières ; dans le cas des rolling release, cela veut dire réparer et adapter au fur et à mesure mais, finalement, le temps de maintenance est court. En gros, si j'ai une ou deux heures dans la semaine, je peux gérer mes maj. À l'inverse, sur les disributions avec release, il faut que j'arrive à me bloquer quelques jours lors de la montée en version. Le premier jour je lis la doc et les retours des utilisateurs, le second j'update, le troisième je répare tout ce qui a cassé… Au niveau temps total passé sur la maintenance, ça doit se valoir, mais pas dans la même "compression" de temps. Et là je remarque qu'avec un emploi du temps qui me laisse moins de temps pour mes bidouilles informatiques, mes rolling releases ont maximum 2 mois de retard tandis que… hem… je n'ai pas encore trouvé le temps de faire l'upgrade de certaines de mes Debian.
D'un autre côté, c'est sûr que ce n'est pas bon de laisser une rolling release sans MAJ durant plusieurs mois, c'est généralement à ce moment qu'on a plein d'ennuis. Alors que les releases à date fixes le supportent bien : il y a les maj de sécurité qui changent peu de chose.
Et Arch, c'est trop bien ! Les seuls moments où je réinstalle c'est quand je change de disque dur, ce qui n'est pas souvent. Parfois je me dis "ça serait bien de repartir de zéro pour faire un grand ménage de tous ces restes de paquets que je n'utilise plus", mais, bon, flemme…
[^] # Re: Arch <3
Posté par Liorel . Évalué à 9.
Petite explication :
pacman -Qtliste les packages qui ne sont dépendance d'aucun package ;pacman -Qdrestreint l'output aux packages installés en tant que dépendance ;pacman -Qqlimite l'output au nom des packages (il retire notamment les numéros de version), indispensable pour quepacman -Raccepte l'entrée ;pacman -Rcs:pacman -Rsdésinstalle ces packages et parcourt l'arbre de leurs dépendances pour retirer toutes les dépendances rendues inutiles ;pacman -Rcnettoie le cache de pacman en même temps, pour libérer un peu plus d'espace disque.En théorie, si on n'utilisait que
pacman -Rcs, on n'aurait presque jamais besoin d'utiliserpacman -Qqdt. En pratique, on aurait parfois un package qui perd une dépendance au cours d'une mise à jour, donc il apparaîtrait quand même quelques orphelins au fil du temps.Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: Arch <3
Posté par Zatalyz (site web personnel) . Évalué à 3.
Ho pas mal comme manip ! Ça va permettre de libérer un peu de place. Mais je pensais aussi à ces trucs installés et que je n'utilise pas (plus), genre un logiciel que j'ai mis pour tester un truc puis que j'ai oublié d'enlever après mes tests, ou un logiciel qui m'a été utile à un moment mais que je n'ai plus utilisé depuis des années. J'en vire parfois quand je les vois passer dans les mises à jour, mais ma liste de paquet a tendance à être un peu ventripotente, d'autant qu'il y a du AUR dedans. Bon, pas grave puisque y'a de la place sur le disque dur, mais j'ai ce vague sentiment que c'est plein de vieux trucs inutiles :D
[^] # Re: Arch <3
Posté par PR . Évalué à 2.
Beaucoup de gentooistes sont passés à Arch ; pas d’équivalent au fichier /var/lib/portage/world ?
(pour info. c’est un bête fichier texte qui contient tous les paquets demandés par l’utilisateur et il est directement éditable)
Mort aux cons !
[^] # Re: Arch <3
Posté par Nibel . Évalué à 6.
Il faut correctement évaluer ton besoin et ta disponibilité pour traiter les problèmes.
Il n'y a pas une solution meilleure que l'autre dans l'absolu, mais il y a une solution meilleure que l'autre selon tes besoins et ta disponibilité.
Si tu n'héberges rien de critique (= tu peux te permettre des petites indispos régulièrement), que tu n'as pas le temps de bloquer plusieurs jours en cas de problème de montées de version, que tu as besoins de paquets presque en fraîcheur upstream, alors héberger sur une rolling peut être intéressant. Il y aura toujours des individus qui te diront que c'est une hérésie. Mais à partir du moment où ils sont incapables de répondre à ton besoin avec une distro figée, autant les laisser parler dans le vent…
Je suis dans la même situation et dans mon cas précis, Arch est strictement plus adaptée à mes besoins et mes contraintes que Debian.
Il y a la commande qu'a donné Liorel qui fait déjà un peu de ménage.
Une fois tous les 4/5 ans je fais un pacman -Q > list.txt et je trie à la mano sur mon poste perso. Parce qu'il y a des paquets qui ne sont pas orphelins mais qui je n'utilise plus du tout et la commande de Liorel n'est pas capable de faire ce tri. Quand j'ai un doute sur un paquet, je le recherche sur le site d'Arch pour m'assurer de son utilité ou non. C'est un peu chronophage mais j'ai pas trouvé de solution capable d'identifier le taux d'utilisation des différents paquets pour faire le tri.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Arch <3
Posté par Liorel . Évalué à 4.
Tu pourrais déjà gagner du temps avec un pacman -Qe, voire pacman -Qet.
Intérêt : ça limite ton output aux packages installés explicitement (pacman -Qe est le complémentaire de pacman -Qd), voire aux packages installés explicitement que tu peux probablement virer sans tout casser (ils ne sont dépendance d'aucun package).
Mine de rien c'est vachement puissant d'enregistrer si un package a été installé explicitement ou en tant que dépendance. Je n'ai pas souvenir d'un équivalent dans apt (mais mon dernier usage d'une Ubuntu doit remonter à 10 ans, donc mes souvenirs sont pas forcément fiables…)
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: Arch <3
Posté par Renault (site web personnel) . Évalué à 3.
Pour info dnf gère ça, tu as du coup des commandes pour nettoyer automatiquement des paquets qui ne sont plus utiles en se basant sur ce genre de critères.
[^] # Re: Arch <3
Posté par Thomas Douillard . Évalué à 6.
des trucs comme « deborphan » existent depuis toujours. Et bien sur apt stocke l’info de si ça a été installé automatiquement en dépendance ou pas. D’ailleurs si tu désinstalles un paquet ceux qui n’ont pas d’autres utilisateurs sont désinstallés automatiquement il me semble, et apt te propose régulièrement de faire le ménage sur les paquets orphelins.
[^] # Re: Arch <3
Posté par Thomas Douillard . Évalué à 1.
(bon, parce que toujours est toujours galvaudé, j’ai consulté le code source de deborphan et ça donne « toujours = pendant tous le 21ème siècle » (et même un peu avant si vous êtes dans le camp du 21ème siècle qui commence en 2001))
[^] # Re: Arch <3
Posté par Zatalyz (site web personnel) . Évalué à 2.
Hooo mais merci !
Pacman est puissant (mais complexe) ; j'avais déjà trouvé quelques commandes utiles pour faire du ménage mais entre ça et ton autre astuce, c'est sacrément plus optimum !
Ça me motive bien pour faire du ménage, ça…
[^] # Re: Arch <3
Posté par Liorel . Évalué à 4.
Et même dans ce cas, ce n'est pas nécessaire ! D'ailleurs, il y a une page de wiki pour ça (de manière générale, il semble exister un genre de règle 34 du wiki d'Arch : si vous pouvez y penser, il existe une page de wiki pour ça).
D'expérience, j'ai pu transférer mon install sur un nouveau disque dur avec un changement de carte mère au passage, et ça s'est bien passé. Ça a été remarquablement simple, le plus long étant le montage du hardware. Après, c'est quand même prudent d'avoir un smartphone pour lire le wiki, et une clé USB pour tout réinstaller en cas de gros coup dur.
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: Arch <3
Posté par ff_unicorn . Évalué à 2.
Je réinstalle Arch quand je souhaite tester de nouvelles choses (nouveau bootloader, nouveau filesystem et ce genre de choses).
Merci beaucoups pour les arguments pacman pour nettoyer ma machine, sur ma workstation je fais un backup de tous mes fichiers de config et je vire tout de temps en temps pour pas me retrouver avec des confs de logiciels que je n’utilise plus.
[^] # Re: Arch <3
Posté par saltimbanque (site web personnel) . Évalué à 2.
as tu un retour à partager sur les bootloader systemd?
[^] # Re: Arch <3
Posté par ff_unicorn . Évalué à 1.
Je n’ai pas essayé systemd-boot, j’ai fait Grub → Syslinux → rEFInd, mais je pense que ce serai intéressant de tester la prochaine fois.
[^] # Re: Arch <3
Posté par ekyo . Évalué à 2.
J'utilise systemd-boot, du très classique, pas de multiboot, pas de partitions chiffrées, que tu ext4, extra fastboot. Et je dois dire que c'est très simple : 2 fichiers de conf, celui de systemd-boot (/boot/loader/loader.conf) et les entrées de boot proprement dites. Toute modif dans ces fichiers est prise en compte au prochain boot.
J'ai installé grub aussi, au cas où, que je peux sélectionner depuis l'uefi. Mais pour le moment aucun souci.
[^] # Re: Arch <3
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Petite correction : j'ai toujours travaillé dans des contextes avec des distros non rolling et ça ne signifie pas qu'on ne met à jour ! En tout cas je mettais toujours à jour la portion du parc dont j'avais la charge, mais juste les mises à jour de sécurité et c'est là toute la différence. Pour le reste, on n'a en effet pas besoin de la dernière version des applications (et la preuve en est que les conteneurs de pas-la-dernière-version ont le vent en poupe parce-que) le développement se fait par exemple sur une branche précise (de Java/PHP/Python/Ruby/etc.)
On parle de combien de serveurs ? Parce-que quand t'as un parc qui chiffre en centaine(s) je ne sais pas s'il y a cette bande passante…
À côté il y a plein d'autres choses à faire que d'être au service des dernières mises à jour de toute ta distribution.
Je suppose que c'est toujours dans le contexte personnel ? Combien de jours ? Mettons une semaine entière, ça te fait 7x24h=168h (faudra quand même compter le temps de bouffe et somme, mais j'exagère volontairement le trait) au bout de 2ans (là aussi c'est exagéré mais on va dire que l'installation est faite en milieu de vie) ? En face 52x2h=104h par an, soit 208h au bout de 2ans. C'est un peu difficilement tenable avec une grosse prod.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Arch <3
Posté par Zatalyz (site web personnel) . Évalué à 3.
Bien sûr, dans un contexte personnel/associatif. Si j'avais une centaine de serveurs à gérer 1) j'espère que je serais payée à ça donc mon temps à y consacrer serait calé dans mes horaires de travail, il y aurait moins de question sur le sujet 2) j'aurais la formation pour automatiser au max 3) ça serait pertinent d'automatiser au max, le temps passé à affiner les automatismes étant largement compensé par le temps gagné sur les centaines de machines.
Typiquement quand on gère 3-4 machines pour des usages assez différents, il y a des choses qui s'automatisent, mais pas mal de choses aussi qui change au fil des évolutions des logiciels et finalement je trouve que maintenir les routines est souvent plus de boulot que d'y faire à la main. Ce n'est pas valable pour tout, mais j'ai assez vite laissé Ansible de côté par exemple, parce que ça n'était pas pertinent sur si peu de machines ET vu ce que j'y faisait. Mais si je devais faire la même chose sur 10 fois plus de machines, ça serait évident qu'Ansible (ou autre) deviendrais temporellement rentable. Les MAJ et les montées en version, c'est la même chose : avec des petits besoins, c'est un peu le bordel parce que test et prod se confondent et qu'on est toujours à négocier entre le plaisir de bidouiller et l'agacement de bidouiller sans fin. En contexte industriel, les pratiques ne sont pas les mêmes, les moyens non plus.
Accessoirement, dans un contexte personnel, prendre une ou deux heures ça se cale assez facilement dans mon emploi du temps, ce n'est pas qu'une question de cumul au fil des ans. Peu importe le temps passé à le faire, je suis payée pareil :P Par contre, j'ai personnellement plus de mal à me plonger sur le marathon des montées en version au fil du temps ; mais j'imagine que cela dépend principalement de ce à quoi ressemble ta vie personnelle, les contraintes à gérer, la charge mentale, etc. C'est juste rarissime que j'ai toute une après-midi libre à consacrer à un truc où je ne serais pas interrompue, et encore plus rare d'avoir ça sur plusieurs jours d'affilés.
[^] # Re: Arch <3
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Voilà, c'est pourquoi j'ai précisé le cadre professionnel avec un nombre conséquent (le fameux bétail par opposition aux animaux de compagnie) et une claire séparation des environnements et tout ça.
Pour le côté perso, ça va dépendre de chacun. Je peux par exemple me libérer un après-midi pour du marathon d'une part et je n'utilise pas les nouvelles fonctionnalités d'autre part, et de plus je peux rester de longues semaines sans utiliser ma machine (je passe plus de temps sur les machines au travail et chez moi j'ai tendance à garder la bécane éteinte) Du coup, chez moi Slackware ou Debian font sens. Par contre, dans une asso où ce serait mon job (i.e. je consacre quelques heures par semaine à leur informatique) et où on testerait souvent des nouveautés, la rolling release ferait sens sans trop y réfléchir.
Dans tous les cas, il faut qu'il y ait le plaisir de bidouiller (que j'ai de moins en moins quand je rentre éreinté du taf avec des bidouilles agaçantes)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Arch <3
Posté par Yves (site web personnel) . Évalué à 2.
Chez moi même pas : en full-LVM, je branche le nouveau disque, je l’ajoute au LVM, je laisse LVM tout bouger d’un disque à l’autre, et ce sans même arrêter d’utiliser le PC :-) et voilà : je peux sortir l’ancien disque du LVM et le débrancher.
# Hé au fait…
Posté par jseb . Évalué à 10.
Je vous ai déjà dit que j'utilise Arch ?
Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
[^] # Re: Hé au fait…
Posté par woffer 🐧 . Évalué à 6.
Oui, c'est Arch iconnue…
[^] # Re: Hé au fait…
Posté par lezardbreton . Évalué à 2.
C'est pas devenu Fedora ce meme ?
# Comparaison ?
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 4.
Est-ce que par hasard, ou pas, traînerait dans le coin un quidam ayant l'expérience d'utilisation d'autres distributions en rolling release qui accepterais de nous faire part de son expérience et des comparaisons entres systèmes? Personnellement, utilisateur de Gentoo depuis de longues années, j'en suis fort satisfait pour ma machine de bureau, mais j'avoue que la déployer sur mes serveurs me fait un peu peur : trop de difficultés à résoudre lorsque les mises à jour n'étaient pas faites régulièrement ; trop d'éléments paraissant nécessité une expertise avancée pour durcir les installations exposées en frontale au grand nain Ternette… Pourtant, par principe remplacer mes Ubuntu LTS par des rolling sans snap et connexion directe à Amazon me paraît une option de plus en plus séduisante.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Comparaison ?
Posté par gUI (Mastodon) . Évalué à 7.
Sans parler de rolling, remplace simplement tes Ubuntu LTS par des Debian.
Je trouve les rolling très bien pour le desktop (c'est le cas pour moi, Gentoo pendant des années puis Arch maintenant), mais je mets tous mes serveurs sous Debian (sans avoir trop réfléchi à une autre solution j'avoue, celle-ci m'allant parfaitement).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Comparaison ?
Posté par saltimbanque (site web personnel) . Évalué à 6.
Je n'ai pas testé mais il te faudrait certainement comparer à openSUSE Tumbleweed qui est assez proche. Il faut qu'on demande à Greg Kroah-Hartman laquelle est mieux !
[^] # Re: Comparaison ?
Posté par Maderios . Évalué à 3.
https://linuxfr.org/users/maderios--2/liens/greg-kroah-hartman-explique-pourquoi-il-utilise-desormais-arch-comme-distribution-favorite
[^] # Re: Comparaison ?
Posté par saltimbanque (site web personnel) . Évalué à 4.
Intéressant oui , comme ce passage
[^] # Re: Comparaison ?
Posté par yal (Mastodon) . Évalué à 9.
Je suis passé de Manjaro (simple à installer et préconfigurée, idéale pour le noob que je suis, mais dont les soucis/bugs de MàJ ont fini par me lasser) à Arch que j'ai trouvée géniale surtout, en tant que noob toujours, son archinstall qui simplifiait tout, et bien plus stable et performante que Manjaro… Pour rapidement me rendre compte que je n'avais pas besoin des trucs les plus à jour pour mon usage. Au contraire, toutes ces màj constantes (même sans aucun souci) ben, ça me gonflait. Ça m'intéresse pas trop de m'occuper de ça.
J'ai donc installé une Debian, pour voir… J'avais tâté de Ubuntu tout au début, ma toute première distro, avant Manjaro et avant Arch, mais ça n'avait pas été terrible sur mon vieux laptop: c'était lent et lourd, et puis les snaps… bof.
Bref, je ne m'attendais pas à un miracle avec Debian mais je voulais essayer. Ça va faire un an de ça et… j'ai cessé de regarder ailleurs ;)
Le premier boot de Debian après installation, ça a été une révélation: rapide — littéralement, c'est la distrib la plus rapide/réactive de toutes celles qui j'ai utilisée sur mon vieux laptop (2011) — et stable. Pas de snaps imposés (mais c'est dispo, pour qui en veut). Surtout, pas de màj à répétition et un ordi qui non seulement ne me fait pas chier mais qui marche aussi bien qu'au premier jour (sauf l'imprimante, mais ça…).
Je suis loin d'être un expert, très loin même, pourtant j'éprouve autant de satisfaction à utiliser Arch que Debian, pacman que apt. Mais deux distribs, Debian s'est juste révélée être le meilleur compromis entre mes besoins (pas planter, me laisser faire absolument tout ce que je veux avec l'ordi sans me faire chier, sans m'imposer tel ou tel type d'outil et sans rien téléphoner à je ne sais qui: là, Arch et Debian sont à égalité) et ma façon d'utiliser l'ordinateur: moins il se rappelle a moi, plus je l'aime et là… c'est Debian qui l'emporte haut la main ;)
[^] # Re: Comparaison ?
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 3.
Merci à tout ceux qui m’ont répondu dans ce file.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
# Manjaro
Posté par Cyprien (site web personnel) . Évalué à 8.
J'utilise et je conseille Manjaro aux personnes autour de moi. Je suis aussi en train de mettre à jour une dépêche que j'avais écrite sur Manjaro.
J'ai déjà installé Endeavour OS, mais elle ne me semble pas aussi "finie" qu'une Manjaro après installation.
Je sais que les dépôts sont différents de ceux de Arch, mais, pour moi, c'est pour mieux tester les nouvelles versions et aussi pouvoir proposer quelque chose de moins "Stock" que Arch.
Quelles sont les autres reproches que tu as à faire à cette distribution pour ne pas la recommander ? (Je ne veux pas polémiquer, juste ajouter quelques avertissements sur ma dépêche).
[^] # Re: Manjaro
Posté par flagos . Évalué à 2.
Ca va faire 6 mois que je suis sur Manjaro pour la machine du boulot, et je trouve le compromis pas trop mal.
Les packages sont mis à jour plutôt rapidement, ce qui permet d'avoir une install toujours à jour, par contre les environnements de bureau comme Gnome vont prendre le temps d'être testés quitte à temporiser un peu.
Perso, c'est un compromis pas trop mal pour ma part sur une machine de dev. Sur une machine dont j'ai moins le temps de m'occuper comme une machine perso, je vais clairement préférer une distribution plus stable.
[^] # Re: Manjaro
Posté par saltimbanque (site web personnel) . Évalué à 4.
J'ai installé Manjaro et, bien qu'utilisable, j'ai été frustré par la documentation - on perd un peu l'intérêt du wiki de Arch car tout n'est plus applicable. Idem, les forums Manjaro sont moins actifs.
Si on pas de chance, on peut se retrouver avec un AUR qui ne marche pas bien sous Manjaro puisque le système supposé (Arch) n'est pas tout à fait celui installé…
Ensuite je pense que l'équipe Manjaro s'embarque dans des personnalisations sans intérêt - j'ai passé du temps à remettre GNOME en mode normal plutôt que personnalisé à-la-Manjaro.
Problème plus rare mais embêtant, le jour où j'ai voulu toucher au noyau, on ne peut pas faire comme sous Arch. J'avoue avoir oublié les détails mais quelque chose comme : Manjaro force ses propres noyaux et les alternatives dispo sous Arch ne sont plus dispos sous Manjaro.
En revanche j'ai énormément apprécié pamac, très bon gestionnaire de paquet graphique qui gère les dépots officiels + AUR + flatpak + snap en indiquant clairement les alternatives. C'est un peu la bonne surprise qui m'incite aujourd'hui à tester "GNOME software" sous Arch et j'ai l'impression que ce dernier a corrigé ses problèmes
de jeunessed'adolescence (lenteur, bugs). Mais bon pamac est juste un gadget amusant qui m'a fait me demander si Linux peut être utilisé sans terminal ( je rigole! pas taper!)[^] # Re: Manjaro
Posté par Cyprien (site web personnel) . Évalué à 2.
Merci pour vos réponses. En fait, je pense que le chemin Arch => Manjaro n'est pas très agréable (un peu comme Debian => Ubuntu). Par contre, je trouve que Manjaro est vraiment très bien pour quelqu'un qui veut juste un PC qui fonctionne sans le tweaker dans tous les sens.
[^] # Garuda Linux
Posté par Psychofox (Mastodon) . Évalué à 3.
Parmi les distros basées sur archlinux et l'installeur calamares, il y a garuda linux.
Par rapport aux autres distros mentionnées, je dirais que l'accent est plus mis sur:
- l'usage du zen-kernel par défaut
- des thèmes par défaut obscurs
- des gui faciliter certaines configurations (garuda assistant, garuda gamer, garuda settings manager)
- l'usage de chaotic-AUR [1]
- de applications par défaut comme librewolf (fork de firefox), micro (editeur texte)
- l'usage de auto-cpufreq, zram, systemd-oomd, ananicy-Cpp par défaut
Par le passé ils hébergeaient de nombreux services façon framasoft avec un nextcloud, un whiteboard, etc mais je crois qu'ils ont été très ambitieux mais que les coûts les ont fait renoncer.
Ils hébergent toujours une instance bitwarden, un privatebin (clone de pastebin) et des moteurs de recherche searx et whoogle.
[1] Chaotic-Aur est une système de build des packages AUR qui facilite l'installation de packages binaires directement.
# 3615 MaLife: HoloIso
Posté par YBoy360 (site web personnel) . Évalué à 7.
J'ai pris ma journée d'hier à installer HoloISO.
C'est la distribution de la Steam Deck, extraite à partir de l'image recovery de la console, sur un de mes PC avec une carte
ATIAMD.Cette distribution est basée sur Arch Linux. Je voulais bidouiller un peu pour bidouiller ensuite la console (et oui, j'en ai une), après installation, tout marche sur ce PC.
Cette distribution utilise Xorg et Plasma 5.23 et boot sur l'environnement gaming de la console. En modifiant la configuration de SDDM pour booter sur Plasma, et celle de Pacman pour ajouter les sources officielles (et kde-testing), Et bah encore une fois, tout marche : Plasma 5.24.90, avec Wayland et OBS Studio (0,2 % de CPU pour l'enregistrement d'un écran 4K …), SAUF l’environnement de la console.
Ce qui m'a impressionné :
- Pas de changement de contexte Framebuffer <-> Wayland Ou serveur X au boot;
- Temps mis pour booter depuis grub est vraiment faible ;
- Et Plasma 5.25 beta, c'est une tuerie …
Je passe sur l'utilisation de Proton en version expérimentale (ça fonctionne vraiment très bien sur les jeux Windows, 4K60FPS sur les quelques gros jeux que j'ai pu tester, avec Mesa), la principale différence avec une Arch classique, c'est juste que les miroirs de Valves ont des versions figées, et un repo pour l’environnement desktop "console".
J'admire la façon dont ça a été fait. Rien à dire, je pensais au début qu'il y aurait du custom dans tous les sens, en fait, c'est une Arch avec Steam et Proton, point. J'aurais aussi pu installer une Arch classique, mais je voulais tester l'image de la console.
[^] # Re: 3615 MaLife: HoloIso
Posté par Nibel . Évalué à 5. Dernière modification le 10 juin 2022 à 00:40.
Merci pour ce retour.
Valve avait choisi une Debian pour son SteamOS 1.0 et 2.0. J'étais enchanté de voir SteamOS 3.0 / HoloISO passer sous Arch. A mon sens Arch est le top en distro Linux pour le jeu vidéo.
Même si finalement c'est juste une Arch avec les produits Valve et des repos Valve, bah c'est largement suffisant à mon sens. C'est clairement un choix technique que je trouve pertinent. En contrepartie on se coupe un peu des plus michus. Mais le Steam Deck n'est de toute façon pas vraiment une console grand public.
J'aime beaucoup les choix que fait Valve pour tout ce qui concerne l'écosystème Linux. Je le répète souvent ici, sans avoir la moindre action chez eux, mais sans Valve le jeu vidéo sous Linux se porterait sans doute beaucoup moins bien aujourd'hui.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: 3615 MaLife: HoloIso
Posté par ekyo . Évalué à 3.
Me concernant je suis un poil plus mitigé pour valve.
Certes ils font avancer le gaming sous linux. Je les remercie pour ça (proton, aco compiler, pilotes amdgpu etc etc).
Mais, plusieurs choses m'agacent chez eux, au point que malgré mes nombreux jeux achetés sur steam, je lui préfère gog sauf pour csgo qui est un jeu valve dispo uniquement sur steam.
Voilà, du coup je les trouve légers sur la qualité de leur développement, et si j'apprécie ce qu'ils ont fait pour le gaming sous linux, je n'ai pas vraiment confiance en eux.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.