Moonz a écrit 3542 commentaires

Et si tu as un retour chariot dans les arguments ? (git commit -m par exemple)

Et si tu dois utiliser l’entrée standard de ton process pour autre chose ?

Spécifique Bash (et assez moche de surcroît, tu perds la localité que tu as avec la syntaxe a || b)

Il y a deux énormes problème en shell : le scoping et les "tableaux".

Pour passer les arguments à une commande, quelle est la bonne manière : cmd "$*", cmd "$@", cmd $* ou cmd $@ ? (hint : sachant que zsh et bash n’ont pas le même comportement en plus…)

Et ça c’est encore la version simple. Supposons que tu veuilles passer tous les arguments à une commande, en les remplaçant d’une certaine façon (par exemple en remplaçant les chemins relatifs par des chemins absolus), comment tu fais ? (vraie question hein, le problème s’est posé à moi il y a quelque jour, ben je suis passé à Python après m’être cassé la tête contre le mur pendant quelques heures)

Les scopes sont très rigolo aussi. Petit jeu : qu’affiche ce programme ?

zenity --forms --text Configuration --title="Configuration" --add-entry="Login" --add-entry "Mot de passe" | IFS='|' read login pwd
echo "Hello, $login"

Réponse : "Hello, ". Le bon programme serait :

zenity --forms --text Configuration --title="Configuration" --add-entry="Login" --add-entry "Mot de passe" | {
IFS='|' read login pwd
echo "Hello, $login"
}

Explications : dans certains cas, le shell fork. S’il fork les variables d’environnement ne sortent pas du fils. Ce qui donne des challenge intéressant comme : comment savoir à l’avance dans quelle situation le shell va forker ? (dans le premier exemple, le fork pour read était loin d’être évident…), et surtout, comment réussir à réorganiser tout ton programme pour qu’il ne fork pas parce que tu as besoin de la variable login au bon endroit ? (dans mon exemple j’ai pas réorganisé, j’ai tout fait dans le fils, mais si j’avais eu besoin de login dans le processus initial…)

Dernier point en shell, il est impossible de choper le code de retour des processus initiaux et intermédiaires dans une chaine de pipes. Ce qui, couplé à des trucs précédents, donne lieu à de grosses grosses prises de tête. Exemple, comment faire pour détecter le cas « téléchargement foiré » dans la chaine suivante ?

curl http://monsite | sed s/toto/tata > test

Le shell est un langage qui est extrêmement intéressant et bien pensé par certains aspects, mais il a aussi d’énormes problèmes.

Pour l’instant, j’ai été extrêmement déçu de tous les client SIP que j’ai testé sous Linux : Empathy qui ne fonctionne tout simplement pas (j’ai sorti Wireshark, et il envoie des paquets SIP malformés…), Jitsi très mal intégré avec PulseAudio (le son au maximum à tous les nouveaux appels, ce qui fait très très mal aux oreilles)…

Et tous ont un énorme défaut : un très très très mauvais filtre anti-bruit. Voire inexistant, j’ai pas regardé le code. J’ai beau avoir un casque-micro, tous mes correspondants se plaignent du bruit de fond. Viber filtre le bruit corrrectement. Teamspeak filtre le bruit correctement. Mon téléphone SIP filtre le bruit correctement. Je n’ai par contre trouvé aucun client SIP libre qui filtre le bruit correctement.

Pour ceux qui ont testé : est-ce que ça vaut le coup de tenter Linphone ? Ou aurait eu le même problème et trouvé une autre solution satisfaisante ?

Et àmha, il existe une solution toute bête: le système de fichier par le réseau (NFS).

Bonne chance pour faire une application iOS/Android qui accède à ces données, y compris sur un réseau qui n’autorise que HTTP/HTTPS.

Bonne chance pour faire de la gestion fine de droits par application, du partage de données.

Bonne chance pour faire un mode offline.

"Nous", c'est la population, ou les peuples vis-à-vis des "puissantes" multinationales. Puissante car nous leur donnons aveuglément notre confience. Mais pourquoi ne pas avoir davantage confiance en nous-même dès le départ ?

Sauf que ces « puissantes multinationales » dont tu parles, c’est justement la partie du peuple qui s’est sortie les doigts du cul pour fournir un service. À peu près toutes les multinationales dans les nouvelles technologies ont commencé de 0.

Qu’ils ne l’ont pas fait selon les termes qui sont en accord avec ton éthique/esthétique personnelle (cad sous forme libre) — ce dont je suis d’accord, moi aussi j’aurais préféré un Gmail libre — ne veut pas dire que « le peuple » ne s’est pas pris en main. Que je sache, Dropbox n’est pas né d’une intervention Divine.

Bill Gates, Larry Page et Mark Zuremberg et font tout autant partie du « peuple » quoi toi et moi (ou Linus Torvalds).

Gitlab peut parfaitement tourner en interne.

Github aussi d’ailleurs, mais faut payer pour ça.

J'ai l'impression que Mozilla est devenu une religion : si on dit du bien, pas de problème (bizarrement on ne me critique jamais quand j'en dit du bien), mais si on critique, c'est innacceptable et la personne qui critique est forcément de mauvaise foi (et à ignorer?).

Tu veux dire, un peu comme tes réactions dès que ça discute de systemd ?

• Je me nique le poignet
• la coque du portable fait de vieux bruit de craquement voulant dire: "tu joues aux cons"

Les deux sont équivalents grosso-modo : je me nique le poignet = il est lourd, donc je dois fournir un certain effort pour le maintenir en équilibre. Je fournis un certain effort = j’impose un stress à la coque qui fait un vieux bruit de craquement.

Autrement dit, l’observation "la coque ne craque plus" ne signifie pas nécessairement "la coque est plus solide", c’est simplement que plus léger = transportable avec un stress moins important sur la coque, indépendamment de la solidité de la coque.

Ma critique est justement dans l'idée qu'il faudrait connaitre la mécanique pour avoir "le droit" de conduire une voiture.

La différence entre frein à main, pédale de frein et frein moteur, c’est pas de la mécanique ? (par exemple)

Linux n’a pas les drivers dont ton écran n’a pas besoin ? J’ai du mal à voir où est le souci du coup.

En fait, plus je te relis, plus je me dis que tu es très très mal parti.

De deux choses l’une :

• Soit ton but est de produire un langage. Dans ce cas tu prends les choses d’un très mauvais angle en lisant le dragon rouge ; c’est un très bon bouquin pour qui veut comprendre les bases d’une toolchain de compilation, mais aujourd’hui on peut très bien écrire un langage sans écrire un compilateur. Et les chaînes de compilation d’aujourd’hui sont bien bien plus évoluées ; jamais tu n’arriveras à leur cheville avec cette approche. Ce serait quelqu’un qui dirait « bon, mon but est de concurrencer Intel. Étape numéro 1 : bouquiner un peu de logique booléenne ». Aujourd’hui, pour faire un langage pour de vrai, soit tu es un géant (et dans ce cas tu ne posterais pas ce genre de questions ici), soit tu t’appuies sur un géant (LLVM au plus bas niveau, Rust/F#/Nim au plus haut niveau, étant donné que plus haut niveau = chemin de moindre résistance)

• Soit ton but est de te faire plaisir en apprenant, et dans ce cas oublie l’idée de « réutiliser un langage existant ». Ce serait comme essayer d’apprendre la mécanique newtonienne en faisant du reverse-engineering sur un airbus.

Bref : dans ton message, un truc n’a absolument rien à faire là, soit le Dragon Book, soit Python. Commence déjà par clarifier ça :)

Dans le désordre :

1. Prend un langage qui n’a aucun (ou presque) mot de clé de base comme Lisp

2. Lua est connu pour être aisément modifiable

3. En Ruby, tu peux quasiment tout faire sans utiliser de mot clé, par exemple tu peux définir une méthode si sur la classe bool pour te permettre de transformer :

if toto then
tata
end

en

toto.si {
tata
}

J’ai ouïe dire que tu peux aussi faire ce genre de chose en F#, SmallTalk, Nim, Scala et Rust. Les versions récentes de JavaScript (Harmony) sont aussi un bon candidat.

1. Si tu veux faire une chaine complète, diriges toi vers LLVM au lieu de vouloir réinventer la roue.

Je laisserai à d’autres le soin de troller sur l’intérêt douteux de la chose :)

C’est écrit dans l’article lié plus haut.

The encoding has traditionally been either ASCII, one of its many derivatives such as ISO/IEC 646 etc., or sometimes EBCDIC. Unicode-based encodings such as UTF-8 and UTF-16 are gradually replacing the older ASCII derivatives limited to 7 or 8 bit codes.

Et j'me souviens aussi que le pilote générique pour l'écran, ça marchait pas forcément sous Windows 9X (on pouvait choisir un autre pilote).

Généralement ça marchait mais en mode dégradé, limité à 640x480 avec 16 bits de profondeur.

Je vois pas ou est marqué "du texte brut" dans ce qui est cité, c'est une interprétation de ta part sur ce que tu estime être clair. Techniquement, du xml serait aussi du texte brut, ça n'a rien de clair en pratique.

« Voici la philosophie Unix : écrire un bon programme qui ne réalise qu’une seule tâche. Écrire des programmes coopérant entre eux. Écrire des programmes qui gèrent des flots de données textuelles, car cette interface est universelle. » (McIlroy)

« La tradition Unix encourage les programmes qui manipulent des formats simples, en mode texte, orientés flot et indépendants des équipements. Unix appelle de tels programmes des filtres ; ils reçoivent un simple flot de texte en entrée, le traitent et génèrent un simple flot de texte en sortie. » (Eric Raymond)

On peut quand même voi comment une simple phrase sorti de son contexte et répété advitam eternam en guise d’épitome d'un ouvrage exposant l'état de l'art de la recherche d'il y a 40 ans dans un domaine bougant à toute vitesse est encore trop compliqué pour que les gens l'utilisent pour exprimer une idée clair.

Je commence à trouver ça curieux qu'un groupe fortement imprégné par l'esprit scientifique en revienne presque à des méthodes shamanique de vénération des textes "anciens" sans avoir le moindre recul vis à vis d'eux et de leur propre position.

Tu interprètes (très) mal la situation à mon avis.

Comme tu dis, Unix est là depuis plus de 40 ans, dans un domaine extrêmement mouvant. Ce n’est probablement pas un hasard ; il y a très certainement des invariants dessous susceptibles d’expliquer sa longévité. La « philosophie Unix » que beaucoup ici traitent avec mépris, c’est justement une tentative d’isoler et expliciter ces invariants, dans l’objectif d’en tirer des leçons pour l’architecture logicielle en général.

Bien sûr, l’analyse peut être fausse, les conclusions erronées voire contreproductives. Mais ce n’est pas en balançant nonchalamment « 40 ans ; trop vieux » (alors qu’au contraire, la longévité serait plutôt bon signe) ou « chamanisme irrationel » (alors que justement, quand on creuse un peu, on se rend compte que la philosophie Unix, elle sort pas d’un chapeau, elle sort d’un gros boulot d’analyse effectué par de nombreuses et éminentes personnes).

Si tu prends l’exemple justement de l’insistance des interfaces textuelles, il y a plusieurs raisons à ça. La plus importante selon moi est la suivante : cela te force à faire une distinction entre la représentation algorithmique de tes données, la représentation fonctionnelle de tes données, et la représentation sémantique de tes données. Représentation algorithmique : comment représenter les données en mémoire pour résoudre efficacement le problème. Représentation fonctionnelle des données : comment communiquer efficacement l’état du problème à la machine. Représentation sémantique des données : comment communiquer efficacement l’état du problème à l’humain. Quand tu forces tes entrées et tes sorties à être textuelles, tu es forcé de te poser ces questions, parce que tu es forcé d’écrire la conversion entre les différentes représentations et ce même si tu n’as pas idée de ces distinctions. Ça te donne quasiment-automatiquement un système aisément débuggable et aisément testable. À contrario, le binaire, en général, ça se passe comme ça : je code mon algorithme. À partir de mon algorithme, je décide comment sont représentées en mémoire les entrées et les sorties. Et de là, je définis mon protocole binaire : en entrée, read(struct ProblemSpecification), en sortie write(struct Solution).

Bien sûr, tu peux très bien faire cette analyse avec un format binaire (par exemple protobuf), et la foirer avec un format texte (pas mal de formats XML en sont un bon exemple effectivement, mais ce n’est pas étonnant si tu gardes en tête l’analyse précédente : beaucoup de formats XML sont juste une image de la structure interne du programme). Mais en pratique, si on accepte l’idée que faire l’analyse poussée des différentes représentations est une bonne idée, alors la spécification des entrées/sorties en format textuel est une bonne méthodologie, parce que les incitations naturelles derrière y tendent. Pour parler très abstraitement, il n’y a pas équivalence entre « protocole textuel » et « bien conçu », mais il y a certainement corrélation.

Ceci n’est qu’une raison parmi un certain nombre, mais mon message commence à être déjà assez long comme ça (et il faudrait que j’aille dormir ;)), et il y a des bouquins entiers qui analysent la « philosophie Unix » de cette manière. Pas en tant que révérence irrationnelle envers un passé idéalisé, mais en tant que leçons pragmatiques à tirer.

La philosophie Unix ce n’est pas un Dieu bienfaisant qui va te garantir le succès si tu répètes quelque mantras. La philosophie Unix ce n’est pas non plus un Dieu colérique qui va te punir si tu ne fais pas exactement comme écrit dans La Loi. Mais c’est la sagesse condensée de gens qui ont fait plus pour l’informatique que tout ce que tu pourras rêver de faire, et il est aussi bon d’avoir un peu d’humilité avant de mettre tout ça à la poubelle d’un revers de main.

Tu peux critiquer la philosophie Unix. Seulement, si tu veux la critiquer efficacement, il faut d’abord la comprendre. Quelqu’un qui dit « philosophie Unix : texte, par exemple json_encode($internalStruct) » est bien plus éloigné de la philosophie Unix que quelqu’un qui dit « OK, mon programme va communiquer en protobuf (binaire), mais que ça ne me dispense pas de réfléchir aux différentes représentations de mon problème ». Mais le plus éloigné de tous, c’est celui qui dit « haha, utiliser du texte en 2015 juste parce que quelqu’un en 1970 a dit que c’était cool ? ridicule ! ». En fait, j’en envie de dire que c’est bel et bien ceux qui l’ont comprise qui sont le mieux placé pour violer les règles. Si je devais faire du 100% « strict philosophie Unix » à mon boulot, ça ferait longtemps que je serais à la porte (parce que bon, un programme en ligne de commande pour le service compta, ça va pas le faire :)) ; par contre, je suis bien placé pour savoir que mon efficacité sur l’analyse du problème et la recherche de solutions provient directement d’un état d’esprit qui découle de la philosophie Unix — et ce d’autant plus que je n’ai pas toujous été « Unixien », et que je vois clairement la différence entre « avant » et « après », en terme d’efficacité.

Plain text

(qui est explicitement écrit dans l’article Text-based protocol)

Ho, et avant de me dire « oui mais texte brut en français c’est pas ça », regardez quelle est la version française de l’article anglais…

(et pour continuer à faire du mal à ces pauvres insectes, « texte brut » est tout à fait clair et fait référence à une dichotomie bien réelle, c’est par opposition à « texte formaté » type .doc/.rtf/.odt)

C’est la séparation d’un problème en sous-problèmes distincts.

Par exemple, pour le problème « je veux compter le nombre de commentaires dans un code python », je peux séparer mon problème en « extraire les commentaires d’un fichier python » (grep '#' < script.py) et « compter le nombre de lignes extraites (| wc -l). Le premier outil se fiche de ce que je veux faire de mon extraction (je pourrai les supprimer, faire une traduction automatique avec Google translate, whatever), le second outil se fiche d’où viennent mes lignes : les deux sont orthogonaux.

L’avantage c’est que je peux tester les outils indépendamment l’un de l’autre, et réutiliser l’un ou l’autre dans d’autres contextes.

ça n'existe tout simplement pas

Text-based protocol

Ce que je retiens, c'est surtout que si ce point de la philosophie unix était important, on tournerais plus sous qnx ou le hurd. Voir même sur darwin, si je me souviens bien.

Si les éviter les bugs était important, on utiliserait aucun outil plus compliqué que ed.

Comme si RH avait le moindre pouvoir sur Canonical, Debian, et surtout son concurrent SUSE.

Bien sûr que oui il en a, non pas en tant que concurrent, mais en tant q’upstream (RH est un très gros contributeur aux projets upstreams, que ce soit du côté du kernel, de Gnome, ou de systemd).

à quel moment systemd va lui donner plus de boulot qu'avant ?

Exemple:

You need the userspace code to set up the bus and its policy and handle
activation. That's not a trivial task. For us, that's what sytemd does
in PID 1. You'd need to come up with an alternative for that.

Lennart Poettering

Note aux altercomprenants qui sévissent dans le coin. Je ne dis pas (je précise : je ne sous-entend même pas) que les devs systemd sont obligés de faire ce qu’on dit parce qu’ils sont nos esclaves (oui, aussi bizarre que ça puisse paraître, il faut préciser ça si on veut pas se faire traiter d’esclavagiste). Tout ce que je dis, c’est que l’assertion « le mouvement dans l’écosystème Linux initié par systemd impose plus de boulot aux développeurs de solutions alternatives » est un fait admis par Lennart lui-même, ce n’est pas une lubie des anti-systemd. D’ailleurs, ceux qui ont un peu de mémoire se souviendront que ça a même été un argument utilisé par Lennart lors du débat systemd/upstart chez Debian : avec tous les changements à venir (chamboulement des cgroups, intégration kdbus/wayland, changements udev…), upstart va avoir beaucoup de difficultés à tenir le rythme :

Anyway, summary is: I wish them good luck, they are now going their own way, stuck in a legacy stack with little new engineering, becoming an island of their own. In the short time frame they might save money with this decision, in the long run this is going to be quite expensive for them, since as our stacks start to diverge more and more adopting systemd later on will get more and more expensive.

Autrement dit : dans le futur, les alternatives à systemd seront forcées de suivre le rythme d’évolution imposé par systemd, et ce sera quelque chose loin d’être trivial.

Voilà : le message est clair : si on arrête pas systemd, Linux va disparaître et Red Hat avec. Il faut stopper Red Hat dans son action suicidaire, etc…

Où arrives-tu à lire ça ?

Le mec il dit :

then you may as well just surrender Linux to them

Et non pas seulement (qui pour le coup irait dans le sens de ton interprétation) :

then you may as well just surrender Linux

Le type ne dit pas que Linux va disparaître, le mec dit que Linux va être approprié par RedHat.

Et là du coup tu vas nous expliquer ce que tu pouvais faire avec sysv que tu ne peux pas faire avec systemd (niveau bidouillage)

Pourquoi est-il nécessaire de le répéter pour la 15e fois ?

La possibilité de changer un composant (par exemple /bin/init) sans avoir à chambouler tout le reste (udev, dbus,…)