Linux? - Page 235

C'est Linus l'opportuniste qui a profité du travail effectué par le projet GNU et du fait que, par pure chance (pour lui), leur noyau (HURD) a pris du retard. Cela aurait pu être n'importe quelle autre pièce, genre le compilateur, mais non, GNU avait tout fait dans l'espace utilisateurs, c'était justement le noyau qui manquait, par pur hasard exactement ce que Linus avait codé pour s'amuser.

[EDIT: faute de frappe corrigée]

Ouais enfin, un retard de 30 ans, on ne voit ça que dans Doctor Who (ou avec Gallileo, c'est vrai).

Oui enfin il y a(vais) du choix hein, si GNU n'etait pas la il y a le userland BSD, le userland de minix et plein d'autres que je ne connais pas ou auquel je ne pense pas.

Nil (./7022) :
Ouais enfin, un retard de 30 ans, on ne voit ça que dans Doctor Who (ou avec Gallileo, c'est vrai).

Plutôt 7 ans, HURD est utilisable depuis au moins 1998, année dans laquelle Debian GNU/Hurd a été lancé. Son problème, c'est que Linux était là avant et que tout le travail de développement va donc dans Linux, donc forcément, HURD n'aura jamais le même niveau de fonctionnalités.

Et si Linus a pu délivrer Linux 7 ans avant HURD, c'est surtout à cause du choix de conception de faire un noyau monolithique, qui a été critiqué dans ce topic:

Lemokitu (./7008) :
Si on reprend son vieil argumentaire sur l'architecture microkernel, oui, il trouve la sécurité secondaire vs. performance pure.

Alors, il faudrait savoir ce que vous voulez: un noyau délivré rapidement (→ Linux) ou un noyau conçu selon les règles de l'art (→ HURD).

genre hurd c'est les règles de l'art...

les perfs de hurd sont dégueulasses et c'est pas du a sa sécurité: c'est du au message passing, c'est le pbm principal de TOUS les uk et ca n'a jamais été résolu. C'est la preuve que ce design ne fonctionne pas.

je te rappelle que les users en ont rien a foutre de l'archi ou de l'acronyme doublement récursif, ils veulent un PC qui marche de manière correcte, ce qu'offre linux au contraire de hurd, qui a échoué, parce que chaque nouvelle "release" est obsolète.

Sinon faut pas déconner non plus, si c'était fait dans les règles de l'art on n'aurait qu'a changer de glibc et tout le reste devrait fonctionner pareil qu'avant.

Je suis bien d'accord avec Linus sur ce point, les microkernels ne servent à rien. Mais je ne suis pas fanatique de la sécurité non plus. La performance compte aussi dans le monde réel.

Ce que je dis, c'est qu'il faut choisir ce qu'on veut, on ne peut pas tout avoir, sécurité et performance, sortie (release) rapide et architecture complexe etc.

Rien n’empêche de faire un noyau dans les règles de l'art et qu'il soit disponible (cf. minix sur lequel les premières versions de linux ont été réalisées, l4, etc). Après, pour ce qui est de l'adoption par le plus grand nombre... Et par ailleurs le message passing n'est pas propre au microkernel, peut être implémenté de façon efficace. Il faut juste éviter d'y laisser des poils de barbe pour que ça fonctionne correctement.

Et sinon, une petite analogie (purement hypothétique évidemment):

Imaginez qu'il existe une équipe de football composée de 10 footballeurs excellents (plus réserves), genre Cristiano Ronaldo et Lionel Messi en attaque etc., et que le problème de cette équipe est qu'il lui manque un gardien du but. Du coup, elle ne peut jouer que des matches amicaux avec des gardiens empruntés. Imaginez maintenant que j'arrive, me présente comme un gardien amateur (c'est la position que je jouais toujours dans les cours d'EPS à l'école en tout cas ) et propose qu'on essaie de jouer ensemble. Imaginez maintenant que l'équipe ainsi formée ait un succès à échelle mondiale, et qu'à cause de ma personnalité, les médias me fêtent déjà comme le nouveau Buffon et commencent à appeler l'équipe "FC Kofler". Imaginez maintenant que, alors que tout le monde sait (parce que je l'ai annoncé dès le départ) que je n'ai jamais prévu de faire du foot à niveau compétitif*, je ne fasse absolument rien pour corriger cette appelation, mais l'utilise au contraire moi-même et donne des entrevues prétendant que j'aie toujours voulu devenir un footballeur, qu'il m'ait juste manqué des joueurs de terrain et que j'aie sélectionné 10 joueurs passables par-ci par-là pour compléter mon équipe. Comment réagiriez-vous?

* histoire de vous divertir, une anecdote (réelle cette fois-ci), à ce sujet:
– Mme. H. (professeur d'EPS) à un de mes camarades: Crache ton chewing-gum!
– Moi: Mais madame, les footballeurs professionnels mâchent souvent des chewing-gums.
– Mme. H.: Si toi, tu deviens un footballeur professionnel, alors je m'appelle Marilyn Monroe.

Kevin Kofler (./7025) :

Nil (./7022) :
Ouais enfin, un retard de 30 ans, on ne voit ça que dans Doctor Who (ou avec Gallileo, c'est vrai).

Plutôt 7 ans, HURD est utilisable depuis au moins 1998

On ne doit pas avoir la même notion d'utilisable

Kevin Kofler (./7025) :
Alors, il faudrait savoir ce que vous voulez: un noyau délivré rapidement (→ Linux) ou un noyau conçu selon les règles de l'art (→ HURD).

C'est vrai, ça : est-ce qu'on veut un noyau qui tourne concrètement depuis plus de 20 ans (Linux), ou un vaporware qui est toujours en stade expérimental après toutes ces années (Hurd) ?

Et tant qu'à faire : est-ce qu'on veut comme chef de projet quelqu'un de pragmatique qui a fait un boulot monstrueux (Linus), ou un idéologue qui n'a plus écrit une ligne de code depuis longtemps et qui passe son temps à faire des conférences pour dire à quel point il hait les softs propriétaires (RMS) ?

Quel choix difficile...

Je choisis Steve Wozniak

Et puis les regles de l'art c'est tres subjectif, faut arreter de se voiler la face

C'est interdit en France de toute façon.

./7027 Je suis d'accord aussi, faut choisir.

Petite débilité avec Red Hat qui m'a niqué deux mois de tests en mettant à jour « ls » et qui a juste arrêté une prod pendant 13 heures « grâce » à ça…



Après discussion sur Twitter, on a pensé un temps au shell appelé qui peut être responsable de ce dawa. Mais je me rappelle maintenant que je lance depuis trois mois le script via cette commande nice --15 /bin/sh/ script.sh (*)
(Oui, un tel niveau de nice est nécessaire pour prioriser ce que je veux faire). Pire encore si on regarde les exemples, on s'aperçoit que le comportement de ls -I est quasiment incohérent entre syntaxes similaires (les lignes ls -artlI thisis* et ls -artlI mybody*) parce que le filtre peut concerner UN ou PLUSIEURS fichiers

Donc, oui, je n'oublierai pas les quotes, mais pour moi, avoir des comportements différents selon l'utilisation des jokers, c'est pour moi un bug, et pas une feature.


[edit] (*) Godzil m'a conseillé d'utiliser /bin/bash à l'avenir

Pourquoi utiliser bash quand sh est suffisant au contraire ? À moins de maitriser l'environnement ou d'avoir explicitement besoin d'une fonctionnalité de bash qui n'existe pas dans sh, autant rester compatible avec un maximum de distributions. Perso je trouve dommage d'avoir régulièrement à rendre des scripts compatibles avec des environnements sur lesquels je n'installe pas bash en remplaçant des shebang en "/bin/bash" et 2 ou 3 basheries qui se réécrivent très bien de façon portable.

J'ai conseillé d'utilsier /bin/bash si il utilise des specificité de bash "never assume that /bin/sh is bash".

Debian/Ubuntu l'a montré mainte fois en liant par defaut /bin/sh avec dash qui a ses avantages, mais aussi l'inconvenient de ne pas etre 100% compatible avec bash, et pas mal de script ecrit avec bash "in mind" ne passe pas avec lui.

En fait, je crois que c'est même pas une histoire de shell, c'est juste que ls -I se vautre quand il y a au moins 2 fichiers à exclure du listing.
Cf. ls -I *my* et ls -l *MY* qui donnent des résultats différents parce que le nombre de fichiers à exclure diffère.


[edit] : eeeet le ticket est fermé car c'est pas un bug :

If you do not quote the operand of -I, it is expanded by the shell before
running the 'ls' command and only the first word produced by the expansion is
used as the operand of -I. The remaining words produced by the expansion are
seen by 'ls' as the list of files to be listed. You can consider using the -x
option of bash to see the exact command being invoked.

Yay.

Godzil (./7038) :
J'ai conseillé d'utilsier /bin/bash si il utilise des specificité de bash "never assume that /bin/sh is bash".

Ah d'accord, dans ce cas

YN_ : je n'ai pas lu ton message en entier (et la police utilisée sur la capture la rend très difficile à lire donc je n'ai pas vraiment regardé) mais ça n'est pas un problème d'expansion qui transforme ton *machin* en plusieurs arguments dont seul le 1er sera pris en compte par l'option -I ?

si

Ah oui c'est même exactement ce que tu as déjà dit dans ./7039, my bad

Ça ne fera jamais qu'un argument supplémentaire contre l'expansion des jokers par le shell, mais les pro-UNIX disent que c'est une feature, alors... ^^

Comme quoi l'erreur n'était pas chez Red Hat. J'allais aussi poster ça immédiatement quand j'ai lu ta capture d'écran, ton erreur se voit de très loin, c'est la première chose qu'on apprend si on apprend à utiliser *nix! Mais d'autres l'ont déjà fait avant moi.

Insulte supprimée

./7043 : c'est quand même bien pratique et ça permet d'avoir un comportement unifié quelle que soit la commande utilisée, tu trouves vraiment que laisser le programme gérer (ou non) l'expansion est une bonne solution ? Ça fait potentiellement beaucoup de code à dupliquer dans tous les programmes, avec le risque que certains l'implémentent mal voire pas du tout. Il suffit de faire un peu de Batch pour avoir une idée du résultat ^^

Le seul argument que je vois contre ça, c'est que certains programmes qui ne prennent pas du tout de fichier en paramètre (ça reste rare) se retrouvent à avoir potentiellement une expansion effectuée alors qu'elle n'aura aucun sens pour eux.

Zeph (./7045) :
./7043 : c'est quand même bien pratique et ça permet d'avoir un comportement unifié quelle que soit la commande utilisée, tu trouves vraiment que laisser le programme gérer (ou non) l'expansion est une bonne solution ? Ça fait potentiellement beaucoup de code à dupliquer dans tous les programmes, avec le risque que certains l'implémentent mal voire pas du tout. Il suffit de faire un peu de Batch pour avoir une idée du résultat ^^

Le seul argument que je vois contre ça, c'est que certains programmes qui ne prennent pas du tout de fichier en paramètre (ça reste rare) se retrouvent à avoir potentiellement une expansion effectuée alors qu'elle n'aura aucun sens pour eux.

Il aurait été pas mal d'avoir un format de binaire / script permettant de décrire les arguments, afin que le programme lui-même puisse décrire l'auto-complétion possible et le type d'expansion pour chaque argument C'est quand même dommage d'avoir le fichier d'autocomplétion qui est à un tout autre endroit que le script lui-même.

Ah oui ça, clairement

Tu proposes un nouveau standard de shell pour rectifier ça ?

Les deux approches ont leurs avantages et leurs inconvénients. Mais ça n'excuse pas le fait de ne pas être au courant de cela si on administre un système GNU/Linux!

Insulte supprimée

Si tu veux te faire aimer davantage, tu devrais éviter d'utiliser ce genre de termes, parce que là tu fais du smash de noob gratuit comme aux débuts de yN, et il me semble que c'est une pratique proscrite sur Ti-Gen.
Je dis ça, je dis rien.

Zeph (./7045) :
Le seul argument que je vois contre ça, c'est que certains programmes qui ne prennent pas du tout de fichier en paramètre (ça reste rare) se retrouvent à avoir potentiellement une expansion effectuée alors qu'elle n'aura aucun sens pour eux.

J'en vois d'autres :
- ça oblige tous les programmes à utiliser la syntaxe "concaténation de nom de fichiers" pour leur ligne de commande, même si ce n'est pas la meilleure solution pour eux
- ça empêche de traiter spécifiquement les jokers (exemple tout bête : demander une confirmation si tu exécutes une commande dangereuse avec "*" comme argument)
- ça empêche le programme de démarrer tant que la liste des fichiers correspondant au pattern n'a pas été constituée, ce qui est gênant s'ils sont nombreux et/ou que le système de fichiers est lent à répondre (par exemple un partage réseau avec une connexion limitée)
- après expansion, ça fait des lignes de commandes potentiellement super longues, avec nécessité d'allouer dynamiquement vu que le nombre de fichiers est inconnu. Assez anecdotique de nos jours j'admets, mais je trouve ça un peu dommage.

Pour moi, la bonne méthode est qu'il y ait une API d'énumération des fichiers qui correspondent à un pattern (pour éviter d'avoir 36 implémentations différentes).

Flan > pour moi c'est carrément le principe "tout est un flux de texte unique" (qui s'applique aussi à la ligne de commande) qui est bancal et limité pour interfacer des applis. Mais j'en ai déjà parlé ^^