Enjolras a écrit 295 commentaires

Il y a eu des dicussion pour founrir les symboles à part, mais en fait, c'est tellement simple de re-compiler avec les symboles de debug que ça ne sert à rien.

La même chose, mais je vois pas quel est le rapport avec la choucroute. C'est pas parce que grub sait pas booter windows que syslinux sait booter windows.

TU ne veux pas.

Votre argument se retourne contre vous "je veux avoir le choix de ne pas utiliser systemd, pourquoi si seule une partie de la communauté veut systemd ça devrait m'impacter ?"

peut devenir :

"je veux avoir le choix d'utiliser systemd, pourquoi le fait qu'une partie de la communauté ne veut pas avoir systemd devrait m'impacter ?"

je me demande si on doit fournir chromium et firefox. Founir que firefox pourrait suffire.
Tiens et d'ailleurs, à quoi bon fournir KDE, seule une partie des utilisateurs Arch le veulent.

Puis tant qu'on y est, on peut aussi virer vim et nano, il y a emacs.
Et, et et…

Une vielle notion d'ergonomie, tu veux dire, comme awk ? Comme euh bash ? AHAH, on ne doit pas avoir la même notion d’ergonomie. J'ai un peu l'impression que ça s'améliore au contraire.

Tout le monde est d'accord avec ça, c'est évident -_- ! C'est toujours mieux d'avoir le choix.
Mais la le problème c'est que personne ne veut maintenir deux implémentations. Donc la question est :
Puisqu'on veut une seule implémentation, et qu'on veut systemd, alors, doit-t-on garder rc.conf ? On s'éloigne du KISS, mais ce n'est pas la faute d'arch. C'est la faute de Red Hat. Et ça tu peux pas y faire grand chose…

Il n'y a que 3 solutions :

• Ne pas supporter systemd
• Maintenir les deux implémentations en paralléle
• Faire cohabiter les deux implémentations.

Tu dis qu'on doit avoir le choix, donc l'option 1 va à l'encontre de tes principes.
Les devs ont trouvé que l'option 2 était trop de boulot, même si c'est a priori une bonne option.
L'option 3 est celle choisie.

Au passage, tu es invité à contribuer au wiki français et pas aux pages internationalisées du wiki .org que tout le monde aimerait bien supprimer.

Tu poses beaucoup de questions et tu n'y réponds pas.

Comme dit plus haut, il serait préférable de garder le choix du rc.conf par défaut

C'est évident qu'il serait préférable d'avoir les deux, personne ne l'a nié. Le fait est qu'on se place dans un cas ou les devs n'ont pas ENVIE d'avoir les deux. Dans ce cas on prend le plus simple à développer pour fournir le maximum d'outils, c'est tout à fait rationnel comme choix, si tu vois plus rationnel, je serais heureux de l'apprendre.

Par ailleurs, pourquoi ne pas avoir choisi un init systemV à l'origine ? Je pense qu'il y avait une ligne directrice sur la façon de faire et d'évoluer et qu'elle est maintenant en sursis.

J'ai essayé de décrire la ligne directrice, si tu n'es pas d'accord propose une autre réponse, parler dans le vide ne sert à rien.

Je passe. Tu mélanges les genres et en vient à parler de "convivialité".

Tiens tu fais parti de ce genre de personne qui se comporte comme "tu as tort, mais c'est tellement débile que j'expliquerais même pas pourquoi je pense que tu as tort" Constructif comme commentaire…

Trouves-moi une distrib sur laquelle on ne peut pas faire ce qu'on veut. Un peu de bon sens. Il s'agit encore une fois du choix par défaut que fait la distrib dont il est réellement question.

Il y a différents niveaux de facilité à faire ça. Avec Arch, si tu veux KDE, tu dois pas désinstaller gnome avant.

Le fait même qu'il y ait par-ci par-là des gens qui se posent des questions autour de mêmes sujets démontre un changement.

Les gens se plaignent d'un changement d'implémentation. je ne vois pas en quoi ça dénote d'un changement de philosophie.

Personne n'a prétendu que systemd était KISS.

Pourquoi ? La réponse est encore une fois simple : parce que personne n'a semble-t-il envie de le faire. C'est pas la peine de débattre des heures la dessus… Tu peux essayer d'inciter des devs à le faire, le faire toi même, postuler comme TU et le mettre dans community, que sais-je.

Ce que tu trouves logiques, au fond OSEF, à moins que tu ne le fasse, ou que tu trouves quelqu'un pour le faire à ta place.

Je dis pas non plus qu'il faille installer systemd à tout prix. Et je trouve que rc.conf était une bonne chose.

Je préfère largement avoir rc.conf que 10 fichiers aux noms absurdes et à la syntaxe incohérente. Par contre, je dis que la décision de supprimer rc.conf n'est pas si irrationnelle que ce qu'on a tendance à l'affirmer.

Sauf que les devs ont décidé se supporter systemd officiellement. Et comme ils ont pas eu envie de coder le wrapper, pour garder les choses simples, ils ont viré rc.conf. Stou.

(et oui un joli glibc 2.16 qui a foiré … et ça se compte en jours),

n'accuse pas Archlinux de ta propre incompétence…

Cela dit des majs qui foirent, ça existe. libjpeg6 par exemple :>

Tu connais pacman ?

Non, un fichier de conf lisible n'a rien à voir avec le KISS. Si tu dois écrire un wrappper de 300 lignes pour exposer ce fichier de conf simple, c'est pas KISS, c'est bloat.

Parce que justement, si tu veux intégrer systemd avec rc.conf, il faut écrire des wrappers.

C'est pas à arch de choisir avec quel outil tu fais ta conf. vim, emacs ce que tu veux. Et si les développeurs GNOME ou grub on décidé qu'il fourniraient d'autres fichiers de conf, tu vas pas demander aux devs Arch de pas les packager…

Bah, oui, autant que possible, les fichiers de conf fournis par les paquets ne sont pas patchés.

Si, d'ailleurs, ABS est inspiré de pkgsrc. Sauf que l'avantage, c'est que le gestionnaire de paquets binaires est mieux. pkg_radd et ses déclinaisons n'est pas tip/top.

Quand a pkgin, il n'a pas la qualité de pacman (encore ?).

Non, il ne sait pas booter windows, il sait appeler le boot loader de windows.

Le wiki français est sur archlinux.fr déjà.

Et, donc, permets moi de le citer :

Archlinux :

Arch Linux tâche de fournir des logiciels dans leur dernière version stable.

Kiss :

Jamais ArchLinux ne prendra l'initiative de cacher ou d'interfacer des fonctionnalités ou des possibilités à l'utilisateur. Si un outil de configuration doit exister, la philosophie d'ArchLinux est de laisser son développement aux auteurs du logiciel

Tu n'as pas compris ce qu'était Arch. Arch ne va pas modifier les logiciels usptream pour les simplifier. Parce que, justement, tenter de rendre KISS ce qui ne l'est pas, c'est forcément impossible : tu veux que pour simplifier les choses, du code soit ajouté. Mais :

Il y a bien sûr plusieurs façons d'être simple : la simplicité selon ArchLinux, c'est une conception sans complications (techniques), sans superflu et dont le code reste simple et élégant.
Jamais ArchLinux ne prendra l'initiative de cacher ou d'interfacer des fonctionnalités ou des possibilités à l'utilisateur. Si un outil de configuration doit exister, la philosophie d'ArchLinux est de laisser son développement aux auteurs du logiciel.

Toi ce que tu demandes c'est de développer des wrappers permettant de cacher la complexité des logiciels distribués, ce qui va à l'encontre de la philosophie d'arch qui propose de faire le moins de moficfication possible, pour garder les choses simples.

Donc, ce n'est pas contre Arch que tu râles, mais contre les devs opensource en général. Ce n'est pas arch qui devient moins KISS, mais les logiciels. Encore que. Tu râles contre les kits et les devs, mais tu ne trouves pas pratique de pouvoir mettre un CD et qu'il soit affiché dans nautilus ? Tu ne trouves pas pratiques de pouvoir mettre en veille ton laptop depuis ton user ? etc etc.

Il faut comprendre que des features avancées demandent… du code plus complexe.

Maintenant, je vais répondre encore une fois ce que j'ai dit 100 fois :
si tu n'es pas content, change les choses au lieu de râler. Surtout que :

De par sa simplicité, ArchLinux permet à l'utilisateur de faire ses propres choix. Il peut alors construire le système qui lui convient, grâce au large choix de paquets à sa disposition. Pour reprendre un mot de Judd Vinet, "Arch est ce que vous en faites !"

je ne sais pas, peut être Fedora.

Suffit de lire le man. L'avantage de pacman c'est que le man est court.

C'est sûr: que dire contre le passage de /lib à /usr/lib ? Que dire contre grub2 ?

C'est toute l'histoire. Puisqu'il n'y a rien ou pas grand chose à dire contre, et que c'est upstream, bah, c'est adopté.

je crois que vous avez râté un passage de la philosophie du projet archlinux. Ces choix, ce n'est pas les développeurs arch qui les font, c'est les développeurs upstream. Les développeurs arch ont fait le choix de suivre les choix upstream, c'est même un peu un des principes fondateurs de arch.

Donc, les devs de grub ayant choisi de ne plus supporter grub1, arch ne supporte plus grub. Dans le milieu du FHS/Red Hat, ils ont décidé de changer /lib en /usr/lib, il n'y a aucun problème grave à le faire, donc arch le fait. Et c'est tout.

Ce que vous critiquez comme la perte de l'âme de archlinux, je le vois plutôt comme une réaffirmation de ses principes !

Non mais moi je m'en fou, je suis parfaitement satisfait par la direction prise.

Sauf pour journald, qui est une merde indescriptible incapable de fonctionner correctement dans des conditions à peine éloignées de l'idéal (exemple, un OOps, ou autre jolie erreur). Un système de log non robuste, ça sert à quoi ? En général, quand tu veux des logs, c'est pour les erreurs, pas pour lire que tout marche bien en détail.

J'abonde dans ce sens, grub 2 fournit un compilateur de conf qu'on n'est pas sommé d'utiliser.
Tu peux :

• écrire directement grub.cfg
• écrire directement une conf custom strictement comme dans grub1 (ah non, linux remplace kernel, quel changement !) et laisser mkconfig copier direcetement ta conf dans le grub.cfg. mkconfig se charge des trucs de kikoos comme la couleur, etc. Mais comme c'est des trucs de kikoo, si tu en as besoin, pleins toi à toi même, ou édite /etc/default/grub (c'est vrai que oui, c'est une syntaxe atrocement complexe, ça définit des variables et ça leur assigne des valeurs :o ! Et puis, faut avouer que le nom des variables n'est pas du tout évocateur ! Ah wait. Si.)

Tu critiques le changement, sans avoir même pris la peine de voir si les outils qui remplacent ce qui disparait vont te convenir ou pas.
Tu dis "ce que j'utilisais n'existe plus, et comme ce qui est neuf est différent, ce qui est neuf est mauvais/ne me plait pas."

Excuse moi, mais je trouve que ton raisonnement est puéril, et trollesque. Dans ton journal il n'y a pas une seule critique construite des nouveaux outils. Mais critiquer le changement, ça ne te semble pas absurde ? Tu crois qu'on ne peut pas changer en mieux ? Tu crois qu'on devrait garder indéfiniment des outils qui marchent et ne pas tenter d'avoir des outils qui marchent mieux ?

Tu peux ne pas aimer systemd, grub2, gnome3, etc. Mais c'est une autre histoire. POur ne pas aimer, il faut avoir testé en conditions réelles pendant un petit moment, et s'être habitué au changement, ton rejet de tout ce qui est neuf est ridicule.

En outre tu sembles dire que tu es pris en otage, que tu es obligé de changé. Bah, en temps qu'utilisateur, oui c'est le cas. Il faudrait commencer à comprendre que dans le monde de l'opensource, quand les projets sont développés par des bénévoles, l'utilisateur n'a AUCUN droit. Il n'a que ce que les développeurs veulent bien lui donner. Il faut comprendre aussi que les développeurs ont aussi leur part dans la décision. Un truc qui peut sembler acceptable pour l'utilisateur peut sembler horrible à maintenir à un développeur. Exemple, gnome-panel. Ou dans une moindre mesure, il paraît, grub1.

Si les développeurs décident de donner autre chose, tu dois t'y plier, utiliser autre chose, ou alors devenir développeur de l'ancien, tu n'as que ces 3 choix. Si ton opinion a quelque poids (aka, si tu ne passes pas ton temps à râler mais que tu l'utilise à t'investir dans le projet), tu parviendras peut être à influencer la décision, mais pas pour des choix aussi importants que ceux là.

  La question est plutôt de savoir où iront ceux qui trouvent que c'est moins bien.

Tu sembles croire qu'il n'y a aucune alternative. C'est faux, il y a :

• le fork
• {open,Net,Free,DragonFly,PC}BSD
• solaris (openIdianna)
• d'autres OS, d'autres distributions comme slackware ou crux qui risquent de resister plus longtemps

je ne connais pas trop libasync, parce que c'est assez récent (enfin, sa publication), mais il me semble que c'est un peu comme lwt. Oui c'est un peu comme les goroutines, sauf que ça peut pas être exécuté dans plusieurs threads. C'est forcément sérialisé. À mois, qu'ils embarquent une autre implémentation d'ocaml, mais ça m'étonnerai.

Cela dit, je crois qu'il y a eu des implémentations d'ocaml sans GC avec un lock global.

for i in $(pacman -Sql core) ; do 
   echo "#$i" >> myList;
done

j'avais oublié q. Chez moi ça marche.

C'est bien le cas de python en tout cas :

def sum(n):
    if n == 1:
        return 1
    else:
        return sum(n-1) + n

sum(998)
498501

sum(999)
RuntimeError: maximum recursion depth exceeded in comparison

Donc, encore une fois, j'appelle pas ça de l'optimisation.

Un vrai shell fourni de la completion. Et les paquets sont groupés.
Puis si tu veux, tu fais

for i in $(pacman -Sl core) ; do 
   echo "#$i" >> myList;
done

vim myList

tu fais x sur le premier caractère de chaque paquet que tu veux installer, puis tu fais

pacman -S <myList

Quelle différence avec le choix de l'installateur ? Aucune j'ai envie de dire. Même nombre de frappe si on execpte la boucle for, mais tu peux faire un oneliner avec sed ou awk si ça t'amuse.