Sommaire
Ce billet raconte comment le petit GUL de Bressuire a adopté Artix comme distribution installée par défaut (quand c'est à nous de choisir).
Le problème
Avec le groupe d’utilisateurs GNU+Linux Gebull nous avons constatés quelques problèmes récurrents dans l’action de notre association :
- l’installation d’une distribution basées sur Debian (Ubuntu / xubuntu / Mint), est périssable
- on écrase généralement avec une version récente, une installation ancienne restée à l’abandon, plutôt que d’affronter la ou les mises à jour majeures requises pour la remettre au goût du jour…
- les utilisateurs auxquels nous avons installé une distribution de ce genre ne font pas les mises à jour, et s’ils les font, pas les mises à jour majeures, et reviennent donc nous voir quelques années plus tard avec un ordinateurs sur lequel il ne peuvent plus installer de nouveau logiciels, leur version n’étant plus supportée par le projet de distribution (en amont).
- choisir une distribution en rolling-release, et indiquer aux utilisateurs de faire les mises à jour devrait pallier à ce problème
- avec Gebull, en laissant chacun installer sa distribution préférée aux personnes faisant appel à nos services, nous avons réussi à installer 3 distributions différentes sur les ordinateurs de deux personnes. Ces personnes ne peuvent du coup pas s’aider entre elles ensuite, et celle ayant deux ordinateurs se sent perdue à chaque utilisation.
- nous sommes pourtant globalement d’accord, dans l’association, pour préférer des distributions légères, basées sur XFCE (et nous installons donc cette variante de nos distributions préférées : Debian/XFCE ; xubuntu ; Mint/XFCE)
- choisir une distribution par défaut, pour les personnes n’ayant pas de préférence a priori devrait pallier à ce problème
Puisque Debian ne fait pas de rolling-release et que nous allons au devant de grands changements dans nos habitudes, autant choisir une distribution moderne et porteuse d’avenir. À ce sujet, le membre le plus technique de l’association a fortement insisté pour que la distribution en question soit basée sur un autre système d’initialisation que SystemD.
En effet ce composant logiciel est principalement développé par une seule entreprise, il est central dans la distribution et ingurgite progressivement tous les autres composants depuis 2010. Il incarne le contraire de la philosophie Unix qui a fait le succès et la robustesse de la famille de système d’exploitation qui nous réuni (et qui peut se résumer à : faire de petits programmes, qui font une seule tâche mais la font bien et collaborent ensuite entre eux pour réaliser de grandes choses).
D’autres points sont listés sur Wikipédia à ce sujet.
La distribution choisie : Artix Linux
Artix Linux est système d’exploitation grand public pour ordinateur, sous la forme d’une distribution de logiciels libres de type GNU+Linux.
Elle fonctionne en développement continu, par petites mises à jour régulières (rolling release) étant basée sur Arch Linux, et ne devrait ainsi pas avoir besoin d’une maintenance experte (comme lors des mises à jour majeures des distributions basées sur Debian : Ubuntu / xubuntu / Mint).
De plus elle est rendue confortable pour les utilisateurs normaux par la reprise de composants graphiques de Manjaro (l'installateur Calamares…).
Enfin Artix Linux permet de choisir son init parmi 4 options affichant la volonté de s'affranchir de la pile logicielle Red Hat / IBM reprise sinon par beaucoup de distributions majeures : SystemD / Waylang / Gnome 3 / Flatpak…
Aide pour installation grand public
L'association a regroupé ses conseils à l'installation d'Artix pour le grand public dans un dépôt Framagit : https://framagit.org/gebull/install
L'idée est principalement de faire la 1ère mise à jour après installation, de paramétrer quelques détails et d'ajouter les programmes qui ne sont pas livrés par défaut (Firefox, Libre Office, VLC, Gimp, Engrampa…).
Elle a également créé un petit script automatisant la plupart de ces opérations.
Le projet officiel comporte également une partie francophone dans son forum, ça nous arrive d'y faire un tour : https://forum.artixlinux.org/index.php/board,35.0.html
Après deux ans
On a pu faire plein de choses avec
Réussir à se mettre tous d'accord sur une distribution n'a pas été facile, mais l'association n'a pas explosé non plus.
J'ai d'abord été agréablement surpris par les gains de perf sur ma machine de l'époque, à utiliser des logiciels plus récents que ceux disponible dans ma précédente Debian stable. J'en ai parlé ici : https://www.grimoire-command.es/2021/why_artix_linux.html
Ensuite nous avons trouvé des solutions pour tous les problèmes rencontrés : installer une imprimante, faire fonctionner Photofiltre via Wine… quand il y a quelque chose qui sort un peu de l'ordinaire on trouve généralement un paquet AUR pour nous tirer d'affaire et le wiki d'Arch Linux mérite sinon sa bonne réputation (quand les choses se compliquent, c'est généralement là qu'on trouve les explications qui permettent de comprendre ce qui se passe et comment s'en sortir).
J'ai aussi décris comment j'ai installé un système chiffré et en RAID 10 sur une machine récente : https://www.grimoire-command.es/2021/artix_linux_on_raid_with_full_encryption.html#_version_fr
Bref Artix ne nous a jamais bloqué et nous restons agréablement surpris de la vitesse d'installation des paquets de la distribution (compressés en .zstd) (si en plus on a la fibre ça accélère bien les mises à jour).
Nul n'est parfait
Toutefois le principe du rolling release arrive avec ses inconvénients : il y a toujours des mises à jour à faire (tous les jours) et toutes les semaines une mise à jour du noyau qui recommande de redémarrer la machine… Ça fait beaucoup d'énergie consacrée au système au quotidien. Si on ne le fait pas, les mises à jour s'accumulent et le noyau ayant été mis à jour, la version en RAM ne reconnaît plus les modules disponibles sur le disque ce qui entraînes des blocages (clés USB qui ne sont plus reconnues notamment).
De plus les mises à jour ne sont pas étudiées et calibrées pour un utilisateur débutant : parfois elles échouent, parfois il faut manuellement mettre à jour le paquet du trousseau de clé de chiffrement de l'équipe de développement avant de pouvoir lancer les autres mises à jour, parfois les mises à jour sont bancales… en pratique, on n'est pas plus rassurés d'envoyer ça dans la nature et l'équipe de développement d'Artix indique que ce n'est pas le cas d'usage qu'ils visent.
Pour ma machine perso je reste avec Artix, parce que ça tiens la route (je veux le client desktop de Delta.Chat ? Y'a un paquet AUR…). Pour un serveur j'installe encore du Debian parce qu'il n'est pas envisageable de rebooter le serveur 2x / semaine à cause des mises à jour du noyau.
Un coup d'œil sur Distrowatch montre qu'MX Linux est n°1 depuis un brave moment et c'est un choix qui était séduisant aussi. SystemD y est optionnel, l'expérience utilisateur y est lisse et léchée (quand le thème sombre par défaut d'Artix pose encore des problèmes avec certaines applications : Scribus, Darktable… ; rien de grave mais on se retrouve avec des boutons noirs sur noir et les utilisateurs grimacent). MX Linux s'annonce comme une "semi-rolling" et elle est basée sur Debian ce qui permet de s'économiser l'apprentissage de pacman et yay (parce qu'il faut au moins deux utilitaires en mode console dans le monde Arch).
# mises à jour
Posté par zurvan . Évalué à 10.
certes, donc pour résoudre le problème des utilisateurs qui ne savent pas faire des mises à jour, vous leur installez une rolling release qui nécessite des mises à jour quotidiennes !
après, c'est sur qu'au moins ils prennent le pli de les faire. Quand j'installe une distribution chez des gens, suivant leur niveau je leur propose de cliquer régulièrement sur l'icône de maj, mais d'expérience peu le font…
Au pire des cas je le fais quand je passe, et pour les mises à jour majeures je peux également m'en occuper : même si ce n'est pas compliqué, ça permet de vérifier qu'ils sont à jour de leurs sauvegardes etc
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: mises à jour
Posté par Glandos . Évalué à 9.
Je plussoie. Pour avoir installé des Ubuntu partout (sauf pour moi, je suis en Debian/testing, la rolling-release de Debian ;)), les màj de version majeure se font sans efforts. Et les màj de LTS aussi, tous les deux ans seulement.
[^] # Re: mises à jour
Posté par freem . Évalué à 4. Dernière modification le 13 septembre 2022 à 23:10.
Je suis pour ma part curieux de savoir le retour d'utilisateurs normaux sur les outils de mise à jour automatique, je crois que debian les as "hérité" d'ubuntu, je ne connais pas leur nom, je sais juste que ça existe. Je ne sais même pas s'il est possible de faire des MàJ majeures avec?
Évidemment, je salue le travail et les raisons du choix politique (car c'est clairement politique ici, politique du LL), il se fait rare, ces derniers temps, de défendre la polyculture qui est la force originelle de linux (qui n'est qu'un noyau «inutile» en soit, sans le reste du code, le CPU n'est qu'un bout de sable raffiné…).
[^] # Re: mises à jour
Posté par ElVirolo (site web personnel) . Évalué à 9. Dernière modification le 14 septembre 2022 à 00:04.
J'ai la même expérience que toi. J'installe en général Linux Mint sur les PC de mes proches qui me demandent que je leur « installe Linux ». Je leur répète un nombre de fois incalculable qu'il leur faut installer les mises à jour, mais seule ma compagne le fait (certainement parce qu'elle a, la pauvre, probablement été encore plus que les autres exposée à mes consignes). De fait, c'est moi qui les installe tous les 36 du mois quand j'ai leur PC sous la main.
Je comprends en revanche qu'ils et elles n'installent pas les upgrades d'une version majeure à l'autre - c'est souvent peu aisé, ou peu évident à trouver dans la GUI.
Par ailleurs, j'adore Arch Linux et l'utilise sur toutes mes machines (portable, serveur, téléphone), mais, comme toi, j'ai du mal à saisir l'intérêt d'une rolling release pour des débutants.
En ce qui concerne systemd, sans vouloir réouvrir une flame war, je dois admettre que je ne comprends rien à toutes ces crispations.
Je suis un utilisateur avancé de GNU/Linux (utilisation quotidienne et intensive depuis plus de quinze ans) mais je reste, aussi, un utilisateur lambda au sens où, souvent, j'ai simplement besoin d'utiliser mon PC sans avoir à peaufiner ou tripatouiller cent mille choses. Du point de vue de l'utilisateur lambda, donc, je dois avouer que systemd, je m'en fiche éperdument. Tout ce dont j'ai besoin de savoir dans les cas où je ne suis pas en train d'écrire un service ou un timer (soit 99% du temps) se résume à
systemctl [--user] [enable | start] [--now] service. C'est tout. Le reste n'a aucune incidence sur moi, et je m'en fiche. Tout ce que je sais, c'est que 1) C'est un logiciel libre 2) Ça marche. Et ça me suffit.Quant au poncif de la « philosophie Unix », de la même façon, j'ai du mal à en saisir l'intérêt. Est-elle obligatoire tout le temps, partout ? Est-elle indispensable ? Je passe plus de la moitié de mon temps dans Emacs, qui est exactement le contraire de la « philosophie Unix » (certains diront que si en coupant les cheveux en quatre, cela dit). Et alors ? Je l'utilise précisément parce qu'il fait plein de choses de façon intégrée, et j'en suis très content. La philosophie truc ou bidule, je m'en fiche un peu, tant que le programme est libre et me convient.
Je suis conscient que j'ai certainement tort et serais ravi d'entendre des arguments rationnels et pragmatiques (c'est-à-dire illustrés de cas concrets et sans « bashing » a priori) sur la question.
Merci pour le journal, c'est un retour intéressant !
edit : pardon, je voulais répondre à zurvan.
[^] # Re: mises à jour
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 3.
En fait, sous Mageia, en tout cas, les mises à jour c’est très simple à faire mais ! Au début, quand on vient de Windows, et qu’on ne sait pas encore qu’elles se font en tâche de fond, on hésite à le faire parce qu’on n’a pas envie de bloquer la machine pendant la mise à jour. Une fois qu’on le sait, ça va.
Personnellement, personne n’avait jugé bon de me préciser que les mises à jour se font en tâche de fond. Quelque chose me dit que c’est assez peu quelque chose que l’on pense à dire aux gens à qui on installe un Linux. P'têt bien qu’il faudrait en toucher deux mots aux personnes avant de leur balancer comme argument clé (j’y ai eu droit) qu’on a deux espaces de travail où que c’est simple (bof) d’avoir des lettres accentuées majuscules.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: mises à jour
Posté par Siltaär (site web personnel) . Évalué à 2.
C'est une question intéressante.
Tout d'abord, c'est vrai que c'est un composant plus proche du noyau que de la surface… moi non plus je ne me sens pas une vocation d'archéologue et j'ignore avec bonheur un certain nombre de composants qui sont sous la surface dans mon système d'exploitation (tant que ça marche, ça n'a pas besoin d'être réparé…).
Pour 99% de la population (à la louche) savoir quel système d'exploitation fait tourner leur navigateur web, c'est déjà se pré-occuper de ce qu'il y a sous la surface. Eux, ils ont une déclaration d'impôts à remplir et ils ne se sont jamais pré-occupé du grammage de leurs formulaires jusque là.
Moi-même, quand je vais acheter de l'argent avec ma carte à un distributeur, ce qui m'intéresse c'est de repartir (vite) avec des billets. Découvrir, lors d'un reboot malencontreux, que cette machine tourne sous Windows, c'est effrayant mais c'est pas mon problème (et ça ne dépend pas de moi).
Alors pourquoi s'intéresser à SystemD ? Il y a déjà beaucoup de ressources à ce sujet pour quelqu'un qui voudrait s'y intéresser (et il y a moyen d'en retrouver à partir d'ici : https://www.grimoire-command.es/2019/unix_init.html )
Vous m'avez vu venir, un premier argument c'est : si vous voyez l'intérêt de faire l'effort d'utiliser GNU+Linux, vous pouvez aussi vous sentir concerné par les composants de votre système, du BIOS au bureau.
Mais prenons le problème dans l'autre sens. Mettons que je sois fondé à vouloir utiliser un init codé dans la philosophie Unix. Bah j'ai dû aller chercher quelque chose d'autre que Debian. Ça m'a demandé beaucoup d'efforts, alors même s'ils ont fait marche arrière depuis (parce que finalement on étaient assez nombreux à le vouloir) je préfère rester sur une distribution qui donne le choix.
Emacs ou vim, je demande juste qu'on me laisse utiliser vim si j'ai envie.
Après, y'a des arguments d'ordre philosophique : c'est monolithique alors qu'Unix était jusque là composé de petits programmes indépendants… moi j'ai envie de continuer à utiliser un système bâti comme ça, alors qu'historiquement c'est Windows le gros truc monolithique, avec l'affichage qui est prioritaire sur le multi-tâches.
Économiquement, c'est développé par une grosse boîte, rachetée par IBM. C'est pas un truc que "la communauté du libre" (j'entends par là : la communauté bénévole) va pouvoir reprendre et maintenir si IBM l'abandonne.
On a plein d'exemple de gros logiciels "libres" mais en lecture seule parce que c'est géré par une grosse boîte, le plus célèbre c'est Chromium.
Firefox aussi c'est un gros truc monolithique, donc c'est difficile d'en coder une alternative, alors c'est la prise d'otage, les enjeux de pouvoir, les dérives commerciales, les compromissions (Amazon en raccourci sur la page d'accueil, Google en moteur de recherche par défaut…) le temps de cerveau disponible volé aux utilisateurs (et il vaut des millions, par paquets de 10, que les GAFAM sont ravis d'investir dans cet accès à plus de marché…). GNU+Linux pour moi, c'est un moyen d'échapper un peu au capitalisme de surveillance, à l'emprise des impérialismes… SystemD (qu'on m'impose) c'est pas une émancipation.
D'un point de vue technique : « Trouver les erreurs c'est deux fois plus dur qu'écrire la première version du code. Donc si tu écris du code aussi intelligemment que possible, tu ne seras, par définition, pas assez intelligent pour le débuguer »
C'est plus facile de débuguer des petits outils qu'une grosse pile de code.
Pour les utilisateurs, ça me semble plus facile de configurer des petits programmes qui s'enchaînent qu'un gros qui fait tout (et qu'on ne sait plus par quel bout prendre).
J'arrête là, en espérant que le débat reste serein.
La liberté ne s'use, que si on ne s'en sert pas.
[^] # Re: mises à jour
Posté par freem . Évalué à 9.
Je me demande comment tordre le cou à ce mythe… j'utilise Debian sous runit, ça juste marche, pas de soucis et, non, je n'ai pas compilé runit, j'ai juste sélectionné le paquet.
Je devrais le compiler, d'ailleurs, parce que le lien symbolique me coûte environ 1.5Mio de RSS par daemon géré, alors que si je compilais soit en statique soit en lien avec muslc au lieu de glibc, ça serait 8Kio (parce qu'en fait j'ai 2 process additionnels par daemon: le gestionnaire, et le logger).
Et ce, depuis avant qu'ils ne mettent systemd par défaut. Je veux bien qu'on tape sur Debian et systemd, mais ça serait pas mal de rester factuel au lieu de répandre des légendes: ça aiderait a garder le débat serein.
Il a toujours été possible d'installer, via le système de paquets et les paquets officiels, un init différent sous Debian (quant a ce que sysVinit+rc.d soient de la "philosophie Unix" je n'en ai pas tant que ça la certitude, après tout, cette philosophie indique que l'outil doit faire une seule tâche, la faire bien, et communiquer avec l'extérieur via stdin/stdout, entres autres?).
Après, malgré que je sois moi-même plutôt contre systemd, il faut reconnaître que c'est un outil qui a eu plusieurs mérites:
Tout ça, c'est lié, et sysVinit ne le fait pas. Rc.d non plus.
Le chien de garde (watchdog), est notamment une fonctionnalité utile quand on commence a vouloir des systèmes autonomes qui s'auto-réparent (dans les limites du faisable). Oui, ça veut dire qu'il est souhaitable qu'un service qui tombe redémarre tout seul (pour éviter de cramer du fioul sur 400Km juste pour faire un redémarrage, par exemple).
C'est faisable avec runit (et les daemontools de manière générale) mais ce n'est pas a franchement parler efficace, en pratique on laisse le travail de gérer les dépendances aux daemons eux-mêmes. Je le sais: je l'ai fait.
Ce simple fait indique que les daemons ne peuvent, de facto, pas faire "une seule chose et la faire bien", et ça encourage a hard-coder la dépendance à un truc tiers, donc a réduire le choix de l'admin pour ses outils.
De ce point de vue, systemd est plus UNIX que sysVinit+rc.d, qu'il a remplacés sur de nombreux systèmes.
Pour ce qui est de la gestion des journaux, il n'est pas impossible que si l'on ne s'était pas farci sysVinit+rc.d pendant des décennies, les daemons auraient adopté plus tôt un comportement plus générique, c'est à dire: émettre par défaut sur stdout ou stderr, en laissant au gestionnaire de services le soin de les rediriger et traiter ou il faut, au lieu de s'appuyer sur syslog, qui est un outil unique pour toutes les instances, fait qui implique que s'il tombe, est corrompu, ou autre, on perds potentiellement tous les logs.
On peut également citer le double-fork-trick.
Encore une fois, systemd (et ici daemontools et ses héritiers le font aussi bien) est largement plus UNIX que les outils qu'il a permis de remplacer.
Moi, bien que je n'aime pas du tout systemd, je lui suis reconnaissant: sans systemd et les problèmes autour, je n'aurai jamais su qu'il était possible aussi simplement de s'affranchir de sysVinit+rc.d, je n'aurai probablement jamais (ou alors bien plus tard) trouvé runit, mon init+gestionnaire de services actuel.
Systemd a beau être une usine à gaz, un monstre de complexité, un framework alors que je préfère les bibliothèques, avoir eu des failles de sécurité réseau… je le trouve malgré tout largement préférable à la situation dont il nous a sortis.
En fait, ironiquement, c'est grâce à systemd que certaines distro, dont debian, ont commencé à supporter plusieurs systèmes d'init pour de vrai (le support des init autres que sysVinit+rc.d dans Debian reste parcellaire, soit, mais avant c'était le vide inter-sidéral).
Et le pire dans tout ça, c'est que malgré mon discours ici plutôt en faveur de systemd, ben, je refuse toujours de l'utiliser, pour mes raisons propres (un init qui dépend de dbus est le genre de trucs qui me chatouillent un peu par exemple).
[^] # Re: mises à jour
Posté par freem . Évalué à 3.
Enfin, pas "toujours", ou du moins pas en juste faisant un
apt-get install, mais très certainement toujours depuis avant que debian ne passe à systemd par défaut.[^] # Re: mises à jour
Posté par Siltaär (site web personnel) . Évalué à 1.
Merci pour cette réponse.
Je voulais préciser que passer à autre chose que sysVinit et RC.d me semble salutaire à moi aussi.
Les gros scripts en vieux shell à pondre pour lancer un "service" avec ce vieux système m'ont toujours parus rébarbatifs.
J'utilise OpenRC pour démarrer ma Artix Linux et je n'ai pas eu à m'en plaindre. J'ai dû le manipuler un peu pour lancer automatiquement le démon CUPS par exemple et ça s'est résumé à lancer la bonne commande d'activation du service (dont le petit fichier de configuration était fourni par la distribution).
Tu m'apprends que c'est possible, merci, je vais étudier ça.
La liberté ne s'use, que si on ne s'en sert pas.
[^] # Re: mises à jour
Posté par freem . Évalué à 4.
Lors d'une itération précédente de debian, on a eu un paquet init qui incluais runit-init dans la liste des options, concrètement c'est juste pour s'assurer que le système est complet, le paquet runit existait déjà avant (mais pas runit-init, il fallait finaliser les choses à la main, pas très difficile cependant).
De nos jours, le paquet init ne fournit plus cette alternative, mais comme je l'ai dis, ce paquet est juste un méta-paquet, pas même essentiel (heureusement!), runit-init est toujours présent, et évite toujours de faire les opérations à la main, tout en fournissant un moyen simple et efficace de savoir si systemd-init essaie de s'inviter "discrètement" via une dépendance indirecte (*) vu qu'ils sont en conflit direct, et grâce au système de dépendances.
J'en profite pour mentionner une fois de plus l'interface ncurses d'
aptitude, qui, bien réglée, rend ce problème trivial à résoudre.Mon conseil:
Ces réglages permettent de réparer les conflits soi-même, d'en minimiser l'existence parce que pas de dépendances inutilisées qui peuvent tirer pas mal de trucs en cascade, donc d'apprendre a quoi servent les paquet présents et d'avoir un système raisonnablement léger, pour un coût de maintenance très faible, l'interface ncurses étant plutôt très bien foutue. Evidemment, elle n'est pas parfaite, loin de la, mais c'est largement supérieur à la CLI d'apt et apt-get, tout en fournissant le même degré de granularité. Quand elle est insuffisante, c'est que le dernier recours est probablement d'utiliser dpkg directement…
*: ça arrive régulièrement "grâce" à
libgtk-3-common, qui dépends dedconf-gsettings-baackend | gsettings-backend, le 1er étant installé par défaut. Celui-ci dépend dedconf-service, qui dépend dedefault-dbus-session-bus | default-dbus-session-busqui sont fournis soit pardbus-user-session, soit pardbus-x11, le 1er étant installé par défaut.Celui-ci dépendant de
libpam-systemdetsystemd, un conflit est généré.La solution est, pour le coup, très simple:
gconf-gsettings-backend, qui est le choix que j'ai fait. Ce paquet dépend degconf-service, qui ne requiert que des instances delibdbus-.*, qui ne nécessitent pas dbus du tout (d'où mon choix: je n'ai, après tout, aucune utilité pour dbus, n'en déplaise aux fanatiques du bureau tout intégré);dbus-x11au lieu dedefault-dbus-session-busoudbus-session-bus(vivement qu'on puisse prendre le car tiens, j'en ai marre de ces bus moi) qui ne dépend pas de systemd, manquerait plus que ça![^] # Re: mises à jour
Posté par ElVirolo (site web personnel) . Évalué à 3.
Merci beaucoup pour ta réponse.
1) Pour la question du choix : je comprends, et j'approuve, mais je doute de sa pertinence en ce qui concerne les utilisateurs lambda. J'aime bien avoir le choix aussi (et manifestement, j'ai choisi systemd), mais je n'ai pas besoin d'avoir le choix du système d'init au sein de ma distribution. Celle-ci m'impose d'ailleurs d'utiliser le noyau Linux, qui est monolithique. Si je ne veux pas utiliser systemd, je n'utilise pas Arch Linux (c'est d'ailleurs ce que vous avez fait), mais ça n'a rien à voir avec systemd. Si je ne veux pas utiliser de noyau monolithique, j'utilise Hurd ou Helios (et je m'amuse bien…). Je comprends que les développeurs d'Arch Linux ne passent pas des mois à offrir le support pour plusieurs systèmes d'init (ou noyaux).
2) La question de la « philosophie Unix »
Le noyau Linux aussi est « monolithique » (certes, c'est très différent de l'exemple que tu donnes mais cela montre que l'argument est à géométrie variable, du moins c'est ce qu'il me semble).
3) La question du contrôle du développement par une grosse entreprise
Peut-être que si :) Et si ce n'est pas le cas, on passera à autre chose, comme on l'a fait dix fois par le passé :) Que ça soit développé par une grosse boîte ne change à mon sens pas grand chose - ou alors quelque chose m'échappe. C'est un logiciel libre, on en fait ce qu'on veut. Si on n'y arrive pas, on fait autre chose, comme pour n'importe quel logiciel libre.
Pour le cas de Firefox, il existe, comme tu le sais, des forks ôtant les fonctionnalités qui gênent ou sont imposées. Pour moi aussi, utiliser des logiciels libre relève de la résistance au capitalisme de surveillance, mais j'ai du mal à voir le rapport avec systemd (ou même les grosses boîtes). La beauté et l'efficacité du libre résident justement dans sa neutralité axiologique. Ce qui compte, c'est la licence du code, pas d'où il vient. L'émancipation qu'il permet est mécanique, elle ne repose ni sur un jugement, ni sur des valeurs.
4) Sur la question du fait que la configuration soit plus aisée avec de petits programmes, mon intuition me fait pencher de ton côté (et souvent, c'est un usage que je préfère d'ailleurs). Mais je suis pas certain qu'un débutant ait besoin de configurer son système d'init tous les quatre matins. Moi-même, alors que je sais écrire un script d'init, recompiler un noyau, écrire des patches (alors que je ne suis pas programmeur, comme un utilisateur lambda), je n'ai quasiment jamais besoin de le faire.
[^] # Re: mises à jour
Posté par freem . Évalué à 4.
Selon wikipedia, le noyau de windows NT est de type hybride, alors que linux est monolithique. Juste pour info.
Ce qui tendrais donc a indiquer qu'au niveau le plus bas, windows est plus unix que les distrib linux :D (selon cette métrique, du moins).
Chacun se fera son opinion de la pertinence de la différence, bien sûr, mais bon, wikipedia reste une référence assez utilisée et reconnue il me semble.
[^] # Re: mises à jour
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Il a dit historiquement… :-) Mais c'est vrai que le noyau de Windows 9x n'existe quasiment plus (enfin, je crois que les version 10 et 11 utilisent le noyau de la lignée NT4)
Linux aussi est hybride dans une certaine mesure et les deux n'ont pas le même niveau d'hybridation (i.e. pas sur les mêmes aspects.) Le virage a commencé en gros avec la 2.4 ou 2.6 je ne sais plus exactement.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: mises à jour
Posté par devnewton 🍺 (site web personnel) . Évalué à 8.
Mes parents font les mises à jour de leur Ubuntu tout seul. C'est devenu très facile, car l'OS propose de les faire régulièrement, il suffit de cliquer et de saisir son mot de passe.
Le plus dur pour eux a été de se souvenir du mot de passe.
J'ai pensé à installer une authentification par clef physique, mais ils vont sans doute perdre la clef…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: mises à jour
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 3.
Les caractères manuscrits sur le papier, sous le ruban adhésif, en bas à droite sous l'écran ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: mises à jour
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 14 septembre 2022 à 08:18.
Je ne vois personnellement pas le souci bien qu'on puisse ne pas être d'accord avec la « justification » avancée. De mon point de vue, il n'y a pas de souci pour la simple et bonne raison que c'est une question de « support » et que l'association installe la distribution sur laquelle elle s'engage à intervenir… Là, effectivement, au vue des ressources (humaines et temporelles) réduites, il vaut mieux ne pas multiplier les distributions en plus de proposer ce qu'on maîtrise.
C'est un retour que j'attendais de ce journal. Parce-que je doute que les mêmes qui ne font pas des mises à jours dispersées sur des semaines les feront si ça doit devenir un sport quotidien.
Pour les gens qui ont certain niveau je m'assure juste qu'il y a les notifications activées : pas besoin de penser à cliquer sur l'icône pour vérifier, et il suffit de rentrer son mot de passe pour initier les mises à jour. (cf commentaire plus tôt de devnewton.)
Pour les autres, je mets en place la mise à jour automatique, mais seulement sur les correctifs de sécurité : les nouvelles fonctionnalités n'ont pas d'intérêt quand on n'en a pas besoin et quand c'est cas il y a la demande explicite.
Idem. Et je ne fais que les passages de versions majeures du coup.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: mises à jour
Posté par Siltaär (site web personnel) . Évalué à 2. Dernière modification le 14 septembre 2022 à 09:48.
Nous n'avons pas beaucoup de retours une fois les machines parties dans la nature. Certaines partent par exemple pour des familles de réfugiés, pour des enfants placés… (nous avons récupéré 50 UC d'un hôpital tout proche et les redistribuons à prix libre).
Pour ceux qui gravitent autour de l'association et avec qui on a l'occasion de reparler : non, ils ne font pas plus de mises à jour.
Certains ont un usage très ponctuel et espacé de leur machine (l'icône a-t-elle le temps d'apparaître ? sachant que la recherche de mise à jour s'effectue après quelques heures d'utilisation. Ont-ils envie de passer du temps en plus devant leur machine au delà de leur obligation première ?).
Certains ont tenté un peu au début (parce que l'aspect tamagochii était amusant, mais ça ne dure qu'un temps), ou ont arrêté après le premier couac apparu lors d'une mise à jour, ayant bien repéré qu'une mise à jour peut rendre leur système bancal et ne s'estimant pas capables de restaurer seuls un fonctionnement normal ou confortable (habituel au moins).
Moins de mises à jour, mais des mises à jour plus fiables et qui se déclenchent automatiquement serait probablement une meilleure solution. Avec peut être un gros bouton "pause" pour éviter la "prise d'otage" à la Windows, qui peut retarder l'extinction de la machine pour faire ses mises à jour…
La liberté ne s'use, que si on ne s'en sert pas.
[^] # Re: mises à jour
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Merci pour ta réponse …qui confirme un peu l'intuition que j'avais.
Cela ne rend pas moins pertinent votre choix si ça vous permet effectivement de faire des mises à niveau d'équivalent de versions majeures plus facilement. :-)
Pour les mises à jour, il faut en effet rechercher la fiabilité en l'absence d'expert-e-s (i.e. que ça puisse se faire sans couac sans que les admins de l'asso soient là) et du coup automatiser. Je le dis surtout pour les mises à jour de sécu (sinon à terme les postes Linux vont finir comme les postes W…)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Mise à jour noyau
Posté par Pierre-Alain TORET (Mastodon) . Évalué à 7.
Une solution pour la fréquence des mises à jour du noyau pourrait être de passer sur le noyau linux-lts qu'offre Archlinux, potentiellement je pense qu'il évolue un peu plus lentement.
[^] # Re: Mise à jour noyau
Posté par ElVirolo (site web personnel) . Évalué à 3.
J'ai fait un comptage au doigt mouillé (j'espère que je ne me suis pas trompé, c'est vraiment à prendre avec des pincettes) :
Pour
linux-lts:$ git --no-pager log --pretty=reference --date-order -E --grep 'upgpkg' | awk '/[0-9]{4}-[0-9]{2}-[0-9]{2}\)$/ {print $NF}' | tr -d ')' | awk -F '-' 'BEGIN {OFS="-"}{print $1,$2}' | uniq -c | awk '{total += $1; count++} END {print total/count}'
4.79508
Pour
linux(on compte le nombre de passages de[testing]à[core]):$ git --no-pager log --pretty=reference --date-order -E --grep 'db-move' | awk '/[0-9]{4}-[0-9]{2}-[0-9]{2}\)$/ {print $NF}' | tr -d ')' | awk -F '-' 'BEGIN {OFS="-"}{print $1,$2}' | uniq -c | awk '{total += $1; count++} END {print total/count}'
6.24427
Chaque chiffre est une fréquence moyenne d'upgrade par mois.
# MX Linux
Posté par MatiuBidule . Évalué à 1.
Salut,
N'ayant pas les problématiques que celles évoquées dans le billet, je ne peux rien dire sur Artix.
Mais je valide surtout des deux mains la note de fin concernant MX Linux : c'est la distrib' qui a sauvé mon petit cœur de libriste, trop noob pour se débrouiller sans accroc et sans casser son système tous les 4 matins. J'étais prêt à renoncer et à repartir vers la prison dorée de la Pomme.
Pour bien voir la qualité du boulot de l'équipe derrière MX, je conseil en particulier la page de présentation des outils https://mxlinux.org/current-release-features/
Il y a vraiment tout ce dont on a besoin et même plus, on peut même créer sa propre saveur de MX en combinant 2 outils intégrés : Snapshot pour sauvegarder l'ensemble du système (avec ou sans données perso) et live-usb maker. Au final On obtient un clone ré-installable de son propre système, c'est assez cool.
Il y a aussi tous les drivers nécessaires installés ou disponibles en un clic, etc.
Les mises à jour sont effectivement sans accroc, c'est un confort psychologique indéniable.
Bref c'est une Debian civilisée, je la conseille très fort.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.