Depuis quelques temps, la communauté archlinux me tape sérieusement sur le système. Il y a une minorité de chouineurs qui, disons-le tout net, au nom d’une vision spécifique du principe KISS s’est opposée aux différentes évolutions qui ont eu lieu depuis la fin juin.
En essayant d’être aussi exhaustif que possible, je citerais :
- Le passage ardu à la nouvelle glibc, car il doit être trop dur de lire la documentation et d’appliquer deux ou trois commandes au lieu de faire les mises à jour comme des bourrins.
- L’abandon de grub 0.97 qui n’est plus maintenu par grub2 qui est plus récent et toujours développé.
- L’abandon de l’outil AIF qui n’a plus de mainteneurs et l’utilisation de scripts qui sont finalement bien conçus et pas si complexe à mettre en route, mais les scripts, quel horreur !
- La déconstruction des fichiers de configuration, qui même si j’ai trouvé le passage un peu difficile à avaler sont bien pratiques au final.
- La lente migration d’Archlinux vers systemd. J’avais déjà parlé de cette lente migration vers ce nouvel ensemble de scripts d’initialisation.
C’est l’annonce non-officielle sur google plus d’une migration annoncée vers systemd qui a une nouvelle fois déclenché les hostilités.
Il faut dire que tout a commencé un peu plus haut par une proposition d’un développeur de la distribution (qui doit s’y connaitre un tant soit peu) de commencer la migration, le temps que les dernières pièces manquantes soient mises au point.
I would suggest to replace iniscript by systemd once the ‘Missing systemd units’ is over. Thus we will avoid duplicating our efforts on two init systems.
Ce qui donne traduit :
Je suggèrerais de remplacer initscript par systemd une fois que les « Missing systemd units » seront terminés. Donc cela nous permettrait d’éviter de doubler nos efforts sur deux systèmes d’initialisation.
Et bien entendu, cette proposition a lancé un fil monstre, digne des pires empoignades geekesque, qui font passer la guéguerre vi contre emacs pour une dispute de cours d’école maternelle. 37 messages au moment où j’écris cet article. La pollution est telle qu’un des développeurs clés a décidé de la jouer « dictatorial » coté évolution de la distribution.
My solution was to unsubscribe to arch-general… So all those long threads have achieved is that I will now make decisions with even less community input.
Ce qui donne traduit :
Ma solution a été de me désinscrire d’arch-general. Tous ces fils interminables ont fini par me convaincre que je prendrais des décisions avec moins de retour de la communauté.
Et tandis que des trous de fesses mal récurés foutent la mouise, le mainteneur de l’ensemble de Gnome, Ionut Biru enfonce le coin dans la porte, maintenir Gnome sans passer par systemd est une horreur :
I wonder if we manage to do the switch before gnome 3.6 comes out. I’m sick and tired of supporting ck and seats and become harder to do so.
I plan to drop consolekit support from gnome and compile it with systemd full support.
Ce qu’on peut traduire par :
Je me demande si on peut gérer le changement avant que gnome 3.6 sorte. J’en ai assez de continuer le support de ck et de seats qui devient de plus en plus difficile.
J’ai planifié l’abandon du support de consolekit pour gnome et de le compiler avec le support complet de systemd.
J’avoue que je me demande si je serais encore sur Archlinux d’ici la fin du mois.
La répétition de ces débats stériles sont en train de m’écoeurer d’une distribution qui me donne énormément de plaisir depuis des années. Et depuis que j’ai installé la Viperr 02 sur le portable qu’on m’a donné, la Fedora Linux 17 me fait de plus en plus de l’oeil. D’ici à ce que je saute le pas…
Une communauté peut attirer des utilisateurs ou les faire fuir. A ce rythme, je crains que la communauté archlinuxienne – du moins une minorité un peu trop bruyante et incapable de se remettre en question – ne la détruise totalement !
Pour bien comprendre l’affaire systemd, il faut bien comprendre le contexte :
* Utilisation de système de fichiers virtuels, difficile à débuguer il me semble — pas gênant pour les non-dev
* Impossible de voir directement si les démons se sont lancés sans erreurs — principalement pour les serveurs
* Utilisation de Dbus dans le PID 1 et surtout un démon en plus à faire tourner sur un serveur — d’après Lennart c’était le seul choix possible
* Le fait que ce soit Linux-only (exit BSD sans compter Debian-kfreeBSD, Debian/HURD, Arch/HURD, toussa) — j’espère que l’on va voir apparaître un équivalent pour BSD/HURD compatible (même fichiers pour les services, même API)
* Pas facilement modifiable — on peut lancer un script en modifiant le fichier du service, en plus le script n’est pas écrasé à chaque màj
Mais contrairement à une croyance populaire, il n’est pas très gros car les remplaçant de cron, atd, inetd, etc sont des petits binaires lancés en parallèle.
Ensuite la peur du changement, de perde la philosophie Unix avec un logiciel fourre-tout, la Lennartophobie (à cause de PulseAudio, ou du fait qu’il dise que Debian/kfreeBSD est un jouet ?), ainsi que la fameuse perte du rc.conf qui est assez symbolique d’Arch Linux. Je ne peut que comprendre le rejet de systemd (premier coup d’œil, cool, deuxième, oulà tue pas la philosophie Unix, troisième coup d’œil, site de Lennart, un peu arrogant mais pragmatique), pour le reste je trouve que c’est injustifié, rapellons-nous que découvrir c’est le changement, découvrir Arch Linux c’est le changement, le
changement, c’est maintenant, fallait bien trouver un remplaçant à (liste non-exhaustive) :* SysV
* Init BSD
* Upstart
* init-ng
* OpenRC
* Mùdur et Çomar
C’est à mon avis une grande opportunité d’unifier un peu ce merdier, la prochaine c’est d’adopter la même arborescence de fichiers, de nommer un maximum de paquets de la même façon, et de promouvoir PackageKit. Parce que pour un gestionnaire de paquet universel, être utilisé uniquement sur Fedora/RHEL, Kubuntu, SUSE/SLES, Foresight,
Moblinet Sabayon ça fait un peu léger.Pour systemd, je suis d’accord, même si ce n’est pas sa cible d’origine, sauf erreur de ma part.
Comme l’on précisé les développeurs de Arch sur les listes, il faudra faire un jour un choix, et systemd a le vent en poupe, car il semble répondre à des questions posés par les anciens systèmes, et surtout, il est neutre. On le trouve aussi bien sur fedora, que sur frugalware, que sur OpenSuSE, Mageia (sauf erreur de ma part), et bien sur archlinux.
Les autres sont plus dépendants de leurs distributions d’origine.
Quant à PackageKit, c’est un moyen comme un autre. Sur une fedora, tu n’es pas obligé d’utilise PK. Il y a toujours yumex voir carrément yum ou rpm pour les puristes de chez puristes 😉
Justement on reproche à Lennart le manque d’intérêt pour les serveurs.
Sinon je sais que PackageKit n’est qu’un frontal au gestionnaire de paquet natif, mais ça nous donne une couche de compatibilité pour des projets comme AppStream.
P.S.: Je t’ai reconnu sur la MLnbsp;!
Les serveurs sont souvent le pré carré des BSDs libres. Sinon, il est que ne pas prendre en compte les serveurs, cela peut paraître dur pour certaines personnes.
Ah, et pour les déçu de Grub 2 il y a toujours Syslinux. Pour GNOME bah c’est quand même triste de devoir « imposer » systemd, surtout pour les gens de chez BSD/HURD.
Dommage que syslinux ne supporte pas encore UEFI qui sera bientôt un « standard » incontournable.
Sinon, imposer… J’avoue que les BSD libre que j’ai testé, c’est très très très souvent KDE ou Xfce par défaut. Gnome largement moins.
Et GNU/Hurd… C’est pas demain, trolldi ?
Malheureusement le développement de Syslinux semble un peu mort… Et GRUB ne semble pas si mal !
Si ça perce un jour, ça fera comme GNU/Linux, serveur/embarqué puis bureau, j’imagine qu’un micro-noyau c’est bien pour enlever tous les modules inutiles genre couche graphique et son pour un serveur (mais de toutes façon il n’y a pas encore de support pour les cartes sons et rien n’est fait côté graphique), enlever la couche réseau pour l’embarqué non relié à Internet, bref ça pourrais permettre de faire des noyaux très allégés (sauf erreur de ma partSi ça perce un jour, ça fera comme GNU/Linux, serveur/embarqué puis bureau, j’imagine qu’un micro-noyau c’est bien pour enlever tous les modules inutiles genre couche graphique et son pour un serveur (mais de toutes façon il n’y a pas encore de support pour les cartes sons et rien n’est fait côté graphique), enlever la couche réseau pour l’embarqué non relié à Internet, bref ça pourrais permettre de faire des noyaux très allégés (sauf erreur de ma partSi ça perce un jour, ça fera comme GNU/Linux, serveur/embarqué puis bureau, j’imagine qu’un micro-noyau c’est bien pour enlever tous les modules inutiles genre couche graphique et son pour un serveur (mais de toutes façon il n’y a pas encore de support pour les cartes sons et rien n’est fait côté graphique), enlever la couche réseau pour l’embarqué non relié à Internet, bref ça pourrais permettre de faire des noyaux très allégés (sauf erreur de ma partSi ça perce un jour, ça fera comme GNU/Linux, serveur/embarqué puis bureau, j’imagine qu’un micro-noyau c’est bien pour enlever tous les modules inutiles genre couche graphique et son pour un serveur (mais de toutes façon il n’y a pas encore de support pour les cartes sons et rien n’est fait côté graphique), enlever la couche réseau pour l’embarqué non relié à Internet, bref ça pourrais permettre de faire des noyaux très allégés (sauf erreur de ma part)
Grub 0.97 fait son âge, et Grub2 est développé en continu depuis des années. J’ai migré vers grub2 à l’époque de la version 1.97, et modulo quelques problèmes pour faire migrer des machines virtuelles de grub 0.97 vers les version 2, aucun gros problème à l’horizon.
Bien que non technicien, je suis entièrement de l’avis de Linus Torvalds sur les micro-noyaux. Bien beau sur le plan théorique, et une horreur sur le plan pratique.
Et après, noyau monolithique avec chargement à la volée des modules ou micro-noyau, je reste neutre. Tant que ça fonctionne, le reste, ça me laisse froid 😀
Certes ils chouinent, mais il y a aussi une bonne réactivité, comme par exemple le support à MATE.
L’éclatement des fichiers de config peut être gênant : par exemple avec la disparition du xorg.conf, il faut rédiger des règles pour lesquelles il n’y a pas, comme dans les anciens /etc/fstab, /etc/rc.conf /etc/X11/xorg.conf, de documentation dans le fichier même (les bien utiles commentaires).
J’aimais bien, dans archlinux, le côté didactique du système lui-même, et je trouve que cela a tendance à disparaître.
Autant la réaction d’une communauté qui, je trouve, entre en contradiction complète avec ses propres principes. Que ça soit l’utilisation de scripts résolument simples et stupides comme à l’installation, des fichiers de configuration qui se cherchent encore un peu mais qui, au fur et à mesure, se perfectionnent en dehors des schémas hérités et qui ont finis par se scléroser (avec la nouvelle mouture, je trouve qu’il est bien plus simple de chrooter une session pour jouer avec une installation qui a bugué).
Pour glibc, c’est de la faute de l’utilisateur si ça déconne : il est prévenu à la mise à jour, sur le site, des commandes sont émises pour l’aider dans la transition, de façon simple, transparente et claire. Si l’utilisateur n’est pas capable de suivre sans chouiner que ça pue, je me demande sérieusement ce qu’il fout sous une distribution minimaliste (qui érige le RTFM en raison, finalement).
Mais même s’il y a des emmerdeurs, comme dans toute communauté, ce n’est pas une distribution que je lâcherais pour autant : je suis séduis par ses choix, je trouve qu’elle se bonifie (netcfg dans systemd, enfin !) et je respecte les choix des mainteneurs (au moins jusqu’à maintenant) dans un effort de mise à jour constante (pas simple à tenir).
Bonne chance à toi si tu t’en vas gambader sous d’autres cieux – j’ai croqué le fruit de la rolling release, je n’en recracherai pas une miette.
Je pourrais dire, en tant que spécialiste de mon domaine, le vélo:
« C’est pas dur, pourtant, de dévoiler une roue de vélo, il suffit juste de lire la documentation ( http://www.sheldonbrown.com/tooltips/truing.html ), et pourtant il y a ENCORE tant de gens qui roulent avec des épaves et qui s’en plaignent que ça devient pénible ».
Je ne dis pas parce que je suis conscient que l’expérience ne s’acquiert pas par la contemplation ou le recopiage de commandes des annonces archlinux mais par une compréhension globale de ce qu’on fait et par un minimum de pratique.
Tout ça, psychologiquement, me fait penser à certains compétiteurs bien contents de pouvoir contempler la médiocrité ambiante. Et c’est super rassurant.
Je ne pratique pas glibc tous les jours.
Le petit souci, c’est que quand la documentation déconne c’est pas agréable… ce lien ( http://archlinux.fr/news/le-repertoire-lib-devient-un-lien-symbolique ) ne mentionne pas curl, alors que celui-ci ( https://wiki.archlinux.org/index.php/DeveloperWiki:usrlib ) le mentionne.
Bon j’ai tout réinstallé la partition /, et dans la bonne humeur!
Je comprends aussi que certains soient réfractaires au changement…
Je reste fidèle à arch parce que je pense qu’à long terme, systemd est bénéfique.
A mon avis toutes les distrib y passeront, sauf peut être ubuntu?
A court terme.. j’ai pas encore essayé mais je vais tester avant de gueuler…
Le fait d’être une rolling release est à mon avis un des plus grands avantages de Arch, même si parfois, à cause de ça, on doit essuyer les plâtres…
Et aussi le fait qu’on *sait* ce qu’on fait, même si parfois il faut consulter la doc… je préfère ça plutôt qu’un clickodrome….
Ce n’est pas sympa de traiter les utilisateurs récalcitrants comme des gamins, ils ont souvent une excellente raison. Les gens n’aiment pas le changement, moi non plus, personnellement quand j’ai un truc qui marche bien je n’ai pas envie qu’on chamboule tout.
C’est un peu pour ça que j’utilise exclusivement des distributions « out-the-box », tous ces conflits et changements internes au système ne me concernent plus. Systemd a été inclus dans Fedora mais en tant qu’utilisateur cela n’a rien changé pour moi.
Les dev de arch ont une excellente raison de migrer vers systemd, ils ont dit que ce serait plus facile à maintenir. Ils ont aussi précisé qu’ils travaillent pour eux, pas pour les utilisateurs. Mais ça ne les empêche pas les gens d’avoir le droit de protester.
Laquelle ? Celle de refuser la nécessaire évolution ?
Entièrement d’accord. Mais rien n’est figé.
Mis à part une plus grande vitesse au démarrage ?
Entre protester et pourrir une liste de publication, il y a une différence, non ?
Tout n’est pas une une histoire d’évolution, passer à systemd dans c’est plus un choix. Et Fedora est la distribution la plus longue à démarrer parmi celles que je connais…
Idem passer à Gnome 3 je vois pas où est l’évolution, les gens n’ont pas perdu de matière grise ou de doigts, la simplification drastique n’est donc pas une nécessité. C’est un choix.
Pour la vitesse de systemd, j’ai personnellement constaté le contraire. Chacun voit midi à sa porte. Certaines personnes apprécieront d’avoir tout, et même le superflu sous les yeux. D’autres préféréront avoir le strict minimum.
Et vu l’intégration d’udev dans systemd, à moins de forker udev, se passer de systemd sera de plus en plus difficile.
Je trouve tout ça décevant de ne pas avoir le choix. Pour ma part, pour mes serveurs, c’est clair que je vais aller avec mdev. Je pense même commencer à prendre connaissance des sources pour contribuer.
Je ne vois pas comment c’est une amélioration dans mon cas, j’ai essayé systemd en VM, j’ai réussi à trouver plein de façon de points faibles pour les init basés sur sockets, comme faire partir et tuer sshd de nombreuses fois, utilisant tellement de ressources que les plus petites machines vont se faire DDOS assez facilement. si ça devient le cas pour httpd ou autres daemon, ça va être une nouvelle façon d’attaquer une cible. En plus que pour ma part, j’initialise mes machines très très rarement, La dernière fois que j’ai fait un reboot de ma machine c’étais justement pour une màj de udev, la fois d’avant c’étais pour le kernel. Que je gagne quelques secondes à l’initialisation n’a donc rien d’extraordinaire.
J’aime bien la vision « Unixienne » de séparer les programmes. Si tu englobes udev, l’init et autres, tu empêches quelqu’un de venir créer quelque chose d’autre d’évolutif. Si je veux créer une autre méthode d’init, je vais me heurter à des gens qui vont prendre le monopole. Et ça, c’est très dérangeant. Si SystemD devient « bloaté », si beaucoup d’autres failles de sécurité viennent à être découvertes, si les développeurs lâchent le projet, il va en devenir quoi?
Je suis développeur pour l’embarqué également, et j’y vois déjà des problèmes. Systemd me bouffe plus de cycles de processeur qu’autres choses. Et ça me fait penser à PulseAudio, ajouter des fonctions dont je n’ai absolument pas besoin, dans des processus plus complexes.
Tant qu’à moi c’est pas une évolution. C’est une alternative. Comme telle, les gens devraient avoir le choix.
Linux est un système d’exploitation universel. Ce qui est intéressant c’est de pouvoir créer un système minimal, que ce soit pour un serveur, un système embarqué, incluant des systèmes plus complexes comme les FPGA. Commencer à déboguer systemd sur des architectures très exotiques, j’ai pas envie. Surtout si il inclus udev, qui lui aussi est souvent problématique . C’est déjà assez difficile comme ça de porter un système complet que nous connaissons depuis des années.
J’ai l’impression de perdre de la liberté dans des logiciels qui sont supposés donner le choix à l’utilisateur.
Pour ma part je suis plus vers Gentoo, donc des outils de configuration et autres, ça fais longtemps que je n’en utilise plus. C’est difficile de tout configurer au début, mais je trouve que c’est bien que les gens comprennent le fonctionnement et configurer leur système comme ils veulent. Donc de ce côté, je suis de ton avis. Si les gens veulent pas passer vers quelque chose de différent seulement parce qu’ils sont trop paresseux pour apprendre des nouvelles techniques, c’est leur problème.
Je suis d’accord aussi pour grub2, encore là il faut lire la documentation et s’adapter, mais je crois que c’est pour le mieux.
Mais encore ici, c’est un bon exemple, si un projet comme systemd décidait d’incorporer en dépendances mutuelles un bootloader comme grub2, disant que ça va augmenter la vitesse de boot de 10 secondes. Nous aurions d’énormes problèmes puisque si nous arrivons sur des projets embarqués ARM, qui utilisent x-loader/u-boot, nous serions confrontés au problème évident que nous ne pouvons pas utiliser grub2, donc pas de systemd, pas de udev, sans udev pas de X. Pourrions-nous considérer ça comme l’évolution? Est-ce que c’est éthiquement bien d’être aussi arrogant et d’aller dans la pensé du : « Moi j’utilise du x86-alike, j’utilise pour le bureau, donc tout le monde devrait faire de même, sinon vous pouvez aller vous faire foutre ».
Le truc du : « C’est moi qui code, donc vous vous soumettez », c’est totalement contraire à la mentalité Communautaire de Linux. Certains programmeurs passent des heures à coder des choses que eux-mêmes n’utiliseront pas, à essayer de faire le plus simple possible pour permettre l’intégration dans d’autres buts que ceux qu’ils veulent en faire. Il faut parfois faire des sacrifices pour la communauté, pour les millions d’autres programmeurs qui ont une vision différente de Linux et qui maintiennent toutes les couches de la communauté. Il faut aussi écouter les les utilisateurs dans tout ça.
Pour la énième fois, je pense – en me trompant – que systemd est prévu pour une cible précise : les machines de bureau. Les serveurs ? Un BSD libre ne conviendrait pas aussi bien ? Simple question, hein.
J’aime aussi le principe du « un outil, une tâche ». Je ne sais pas pourquoi, mais je sens que udev va être forké. C’est la force du libre de pouvoir forker non ?
Et quant aux projets abandonnés, ce sont les aléas de la vie.
Dans ce cas, pourquoi ne pas utiliser des OS plus adaptés que GNU/Linux pour l’embarqué en libre ? Je pose la question, hein.
Je me demande pourquoi intégrer grub2 à systemd. Les deux ont deux fonctions différentes, bien que complémentaire. Quant à l’architecture ARM, chaque fois que j’y jette un oeil, j’ai l’impression que 15 nouvelles architectures incompatibles entre elles sont sorties.
Tiens, pourquoi je pense à un fil sur alt.os.minix « Linux is obsolete » ? 😀
Enfin, entre écouter les utilisateurs et vivre sous la dictature des utilisateurs qui ne voient pas la nécessaire évolution de certaines technologies, il y a une différence.
Prenons le cas de la slackware : quel est le surnom de Patrick Volderking, déjà ?
Enfin, sur le coté universel de Linux, c’est plus une évolution forcée qu’une volonté de départ. C’est juste un noyau hobby qui a pris du galon, et qui est devenu passe-partout par la force des choses. Et je pense qu’on peut trouver un nombre impressionnant de critiques de Linus Torvalds sur certains ports, spécialement sur les versions ARM du code.
Merci d’avoir répondu. Je me rend compte que j’ai beaucoup tapé à ce moment là. Haha.
BSD pour les serveurs n’est pas une mauvaise idée. J’y ai pensé, c’est toujours une possibilité.
Pour ce qui est des OS spécialisés sur ARM. J’aime pas trop Android. Et les autres distribution GNU/Linux sont très en retard.
J’aime bien Gentoo, principalement parce que j’aime partir d’un stage1&2 et tout compiler de façon optimisé pour le système ciblé. Comme tu l’as dit, ARM a beaucoup de contradictions dans les sous-architectures. Même dans le ARMv7, pour l’instant je suis sur l’OMAP4460(PandaBoard ES), et si tu optimises pas ta toolchain et que tu compiles pas avec précision, les performances sont de très loin altérés, comme compiler Armel, ça fonctionne, certes, mais les performances sont très altérés si tu compares à compiler avec HardFloat. Même chose pour FPU, tu dois choisir entre l’inter-compatibilité ou la performance, si tu choisis de compiler avec Neon, tu vas voir des améliorations mais tu peux oublier aller vers le Tegra avec tes binaires.
Sinon, ce que j’aime aussi, c’est le choix de compiler ce que je veux, laisser de côté les modules dont j’ai pas besoin et qui sont malheureusement pré-compilés et chargés automatiquement sur la plupart des autres distributions. J’aime aussi le système d’ebuild, de pouvoir pointer un ebuild vers un GIT de développement, ainsi rester « cutting edge », même si souvent il faut bidouiller des patch, qui sont aussi très facile à créer et incorporer aux ebuild.
Il y a la facette développement matériel. je fais beaucoup d’électronique, GNU/Linux me permet d’avoir accès à beaucoup de sources, comme des drivers, sur lesquels je peux me baser pour faire les miens. Sur Android, j’ai JAMAIS réussi à intégrer la plupart des mes projets, comme un bon, exemple, j’ai fais une batterie pour mon Panda, j’ai incorporé à l’expansion un indicateur de charge, qui n’a pas fonctionné sur Android, mais a très bien fonctionné sur GNU/Linux, directement dans le kernel et automatiquement reconnu.
Il y a plein d’autres fonctions également que j’ai vu des ratés, le probe de la température du coeur, le « scaling » du CPU. Pouvoir faire des scripts qui sont utiles en développement, comme de pouvoir lowerclock automatiquement les coeurs si la température dépasse les 80 degrés Celsius. Jusqu’à présent sur Android j’ai eu deux disjonctions thermal.
Mais bon, pour faire plus court. GNU/Linux, t’as le choix, tu peux choisir ce que tu met, comment tu l’intégres, quel WM tu veux utiliser, pouvoir le configurer au plaisir. Tu as des applications très matures, même si parfois pas aussi élégants que je le souhaiterais.
Sinon, je suis de ton avis, mais ça prend des utilisateurs, qui souvent vont devenir des testeurs, des débogueurs ou des développeurs. La puissance d’une distribution est quand même sa popularité, non? Les infrastructures, le matériel, la bande passante, tout ça c’est quand même coûteux. Et même si la plupart de nous le faisons simplement pour l’accomplissement personnel, l’épanouissement de la communauté ou par pur plaisir. C’est quand même agréable d’avoir un petit revenu sur des milliers d’heures de travail. Viser les entreprises, ça vaut la peine. Mais nous avons Windows qui, au Canada en tout cas, est un très gros joueur. Les gens préfèrent encore aller vers M$, par méconnaissance ou ici parce que les IT reçoivent d’énormes pots de vin pour convaincre le PDG d’acheter des licences M$. C’est difficile de gagner sa croûte. Un support par donations ou encore par la publicité des utilisateurs n’est pas négligeable. Même si la plupart ne savent pas du tout de quoi ils parlent etqu’ils sont très cons. Ça ne veut pas dire que leur opinion n’a pas de valeur. Il a des gens avec des bonnes raisons dans toute cette merde.
Ce qui m’a énervé très vite, c’est gnome et ses chamboulements futiles. Gnome3, puis Unity… beurk.
Entre autres chamboulements de logiciels qui parfois sont pas si intéressants…
Du coup je suis passé à TWM + XDM. Ça fait marrer du monde, mais n’empêche que j’ai quelque chose qui est pratique et léger.
Pour les changements d’archlinux. Ils n’ont pas l’air mal.
Ce qui m’a énervé c’est pas les changements, mais comme je l’ai dit plus haut la carence de l’annonce qui n’a pas mentionné curl alors que le wiki le mentionnait.
Du coup je me suis retrouvé à chercher sur les forums, à essayer plein de solutions, puis à finir par réinstaller tout le / par paresse, manque de connaissances sur ce sujet, et surtout par manque de temps.
C’est pas désagréable de réinstaller. On découvre des nouveautés. 🙂
C’est sûr qu’il y a de gros changements sur Arch, et ce n’est pas toujours facile à suivre ! Mais je ne comprends pas non plus les plaintes des utilisateurs, Arch est en développement permanent, il ne faut pas l’oublier.
Je pense que le passage à Grub2 est une bonne chose, grub-legacy était viellissant et peut-être plus approprié aux besoins actuels. Pour ma part Grub2 gère le boot de 3 OS sans problème.
Pour l’abandon (provisoire?) d’AIF, on s’habitue vite à utiliser des scripts, quitte à essayer d’abord dans une VM.
Et pour systemd, c’est une nouvelle méthode qu’il faudra apprendre à utiliser, laissons aux dév le temps de bien l’intégrer dans le système, et au wiki de se compléter! Là aussi, des essais en VM sont à faire, et au pire une réinstall du système.
C’est ce que je me tue à faire comprendre : en cas de doute, faites-vous la main avec une machine virtuelle. les scripts, bien qu’austère sont aussi puissants que l’interface AIF.
Quant à Grub, un énorme +1 🙂
Un post d’Allan McRae a propos des dernières contreverses d’Arch : http://allanmcrae.com/2012/08/are-we-removing-what-defines-arch-linux/
Je l’avais déjà lu. Et en effet, il remet pas mal de points sur les « i » et de barres sur les « t ».
Ça serait bête que tu partes rien qu’à cause des chouineurs… Je te rassure, il y en a aussi, voire plus, dans les autres distro… Et il vaut mieux rester pour les gens bien que partir à cause des gens nuls.
De toute façon, le grand public est par nature conservateur, alors… Y compris le grand public d’un truc pourtant assez pointu comme la communauté Arch.
J’ai testé arch linux il y a quelques mois mais par manque de temps j’ai laissé tombé.
Mais à l’époque je n’avais pas trouvé ça compliqué.
J’ai réessayé dernièrement avec la dernière iso et là je trouve que ça devient galère.
Par exemple si l’on suit le wiki aussi bien anglophone que français on nous parle du fichier hostname à renseigner. Sauf que ce fichier n’existe pas, il faut le créer? est ce un bug?
Plus tard on se retrouve avec un message d’erreur concernant la locale française.
Je trouve que la configuration centralisée par le biais du fichier rc.conf était plus pratique.
Je ne vais pas cracher sur cette distribution car je sais qu’elle a énormément de succès et qu’elle est robuste. Mais quand j’entends parler de philosophie kiss, ça me fait halluciner.
Tout ça pour dire que arch avait possibilité de s’ouvrir à un plus large public et là on retombe dans une usine à gaz. C’est vraiment dommage.
Les connaisseurs peuvent s’en sortit mais ceux qui ne connaissent pas risquent de laisser tomber alors qu’à la base, je me répète, il n’y a rien de sorcier.
En 2012, se taper des lignes de commandes pour installer un OS, j’ai franchement du mal à comprendre. Alors qu’il y a 20 ans je possédait une formidable machine du nom d’amiga (RIP 🙁 ) ou je n’ai jamais eu à rentrer quoi que ce soit dans le shell pourtant je bidouillais pas mal.
PS: Bonne continuation à ton blog que je lis tous les jours même si je suis pas d’accord avec ce post 😀
Les scripts d’installation permettent d’aprivoiser largement mieux l’installation qu’un programmes en ncurses.
Il est vrai que des fichiers précréés seraient bien agréable à l’emploi. Et une fois configuré, tu n’y touches plus. C’est quoi ? 15 minutes de galères pour des mois de tranquillité ?
L’interface texte est le plus petit dénominateur commun. Et jusqu’à preuve du contraire, ce que l’on lit, c’est du texte, pas des icones 😀