Michaël a écrit 2935 commentaires

Oui voilà, c'est à peu près mon avis aussi: on ne sait pas trop à quoi les notes servent mais c'est rigolo, et personne ne nous oblige à les prendre vraiment au sérieux.

Comme tout le monde je suis navré que certains se désinscrivent ou trouvent la communauté fermée à cause de mauvaises notes en série, mais à mon avis ce genre de sensibilité finira toujours par se cristalliser sur un aspect ou l'autre de la participation.

De plus je ne vois pas l'intérêt de régler un “problème humain” par une solution technique. Si Alice et Bob ne peuvent pas supporter la façon de s'exprimer de Victor, et bien cela ressortira toujours d'une manière ou d'une autre, avec ou sans pertinentage.

Quelqu'un semble s'en être ramassé plus que ce qu'il ne pouvait en supporter et s'est désinscrit, la communauté a réagi assez fortement en lui montrant qu'elle n'était pas indifférente à ce départ et en insistant sur l'attention trop importante qu'avait porté ce membre sur ces notes. Bref, tout s'est assez bien passé, en somme.

Et sinon, j'ai une proposition rigolote: pendant le carnaval — temps où la société inverse ses valeurs — on inverse tous les votes et on échange les karmas.

Parcourant les commentaires de la dépêche sur Open Office, je tombe sur des commentaires sur l'échec ou pas de linux sur le bureau. Ça me stimule… gnnééé

Depuis 4-5 ans on entend de plus en plus parler d'administrations qui “passent” à Linux. Cela veut dire que:

1. Il existe des sociétés qui vendent du “Linux pour le bureau.”
2. Il existe des clients qui achètent du “Linux pour le bureau.
3. Il existe une base d'utilisateurs professionnels qui peuvent tenter de faire le pas pour leur usage privé ou le recommander à leurs amis.

Moi je dirais plutôt que “Linux pour le bureau” est en bonne voie de réussir.

Linux ne se vend pas et ce paradigme différent par rapport aux autres sus-cités change la donne qu'on le veuille ou non, dans la tête des entrepreneurs des industriels et des con-sommateurs, le capitalisme a bien réussi à nous faire nous méfier du gratuit (et encore plus du libre).

Parceque RedHat, Suse et iXsystems, ils vendent des esquimaux au chocolat?

le capitalisme a bien réussi à nous faire nous méfier du gratuit (et encore plus du libre).

On pense tout particulièrement à Facebook, Twitter, Google, … que de méfiance dans le grand public vis-à-vis de ces services (apparemment) gratuits.

Désolé mais tes stéréotypes ne correspondent pas à ce que je vois.

Les moteurs de rendus HTML sont loin d'être à la hauteur sur certains détails mais c'est une autre histoire ;-)

Si on parle de typographie fine, c'est assez loin d'être une autre histoire.

Ceci dis, comme pour le HTML, à ma connaissance, rien n'est écrit noir sur blanc!

Tous les algorithmes de TeX sont soigneusement documentés et il y a même des implémentations alternatives en OCaml ou Java (ou du moins des projets pour le faire, mais vu que ça ne sert à rien, ce genre de chose s'arrête tout seul).

Je suis plutôt d'accord avec Sytoka Modon sur le fait que le html/css peut être compris comme un langage de formatage de textes à l'image des langages Troff et Tex.

Ce n'est pas la question, on parle de typographie fine…

l'interprétation des langages Troff et Tex est stricte (même code, même rendu),
l'interprétation du langage html/css ne l'est pas.

donc exit html/css pour la typographie fine.

Ce n'est pas que ce que vous dites est faux ou inintéressant, c'est juste HS.

Je suit justement la discution

On ne dirait pas. Nous on parle des cas de typographie compliquée

moi, je veux bien mais de quoi on parle quand on dit "typographie compliquée" ?

Et bien en gros, il s'agit des tableaux et des équations.

Et toi tu viens nous parler des cas de typographie simple (là où, en gros, il n'y en a pas):

Idem, en TeX (LaTeX), tu peux faire un document très propre sans forme. C'est
d'ailleurs très souvent le cas…

J'en ai parlé à mon livreur de pizza, il pense aussi que tu es à côté de la plaque.

Bref, le CSS est intégré dans le HTML et complètement fusionné via cette balise.

CSS et HTML sont deux “normes” distinctes.

Donc pour moi, HTML est vraiment du même coté que TROFF ou TeX.

À mon avis, tu devrais recompter le nombre de fois qu'il y a écrit may dans la norme de CSS!

Oui pour Markdown et DocBook mais en HTML, tu peux mélanger du fond et de la forme comme en TeX.

Tu peux, mais l'évolution de la norme est plutôt de supprimer tous les attributs de style explicites du HTML pour les déplacer dans CSS et j'ai la flemme de vérifier mais tous les attributs de style explicite dans HTML sont probablement obsolètes (deprecated).

De plus les attributs de style ne sont pas contraignants (autrement dit, c'est de la décoration), ce qui fait une légère différence avec TeX et troff, pour lesquels au contraire ces attributs sont cruciaux.

Idem, en TeX (LaTeX), tu peux faire un document très propre sans forme. C'est d'ailleurs très souvent le cas…

Apparemment tu ne suis pas trop la discussion, là on parle justement du cas où ce n'est pas possible.

moi, je veux bien mais de quoi on parle quand on dit "typographie compliquée" ?

Et bien en gros, il s'agit des tableaux et des équations. Ce type de préparation est très difficile à généraliser, à preuve la complexité des packages des macros pour la préparation de tableaux disponibles pour LaTeX.

Par exemple, dans ces deux types de préparation, il est courant de placer des gabarits pour corriger les alignements, d'utiliser des élément invisibles, de faire du kerning, etc. et toutes ces choses là sont difficiles ou impossible à faire avec HTML, Markdown ou DocBook, parceque ces descriptions sont très éloignées du support physique.

Sans compter les mégaoctets de documents qu'ils permettent de préparer.

je n'ai pas compris :-(

Il existe des mégaoctets de documents pour TeX et troff, deux excellentes raisons pour continuer de mettre à jour ces logiciels.

% env BLOCKSIZE=k du -s /usr/local/man/man* /usr/share/man/man* | awk '{t+=$1}END{print(t)}'
54472

Sur ma machine il y a 54 Mo de pages de man, comme elles sont compressées on est assez proches de la quantité d'information. Pour TeX en regardant ce qui est publié chaque jour sur arXiv.org, vu qu'un article typique fait plus de 150ko comprimé, on peut dire que la quantité de documents écrits en TeX croit de plusieurs Mo tous les jours.

Mais TeX, j'ai toujours trouvé ça très pénible pour faire des mises en pages complexes et personnalisée.

Quelque soit le logiciel utilisé, c'est très difficile de réaliser des mises en pages complexes et personnalisées — qui soient réussies, s'entend — et typographe ou graphic designer sont des métiers. Avec TeX on est bien obligé de laisser ça à des professionnels, avec un WYSISWYG classique on obtient invariablement un résultat attendrissant comme un collier de nouilles colorées pour la fête des mères.

Les deux ne sont pas antinomiques, certes…

Le but de mon exemple est de démontrer que troff est très près du rendu physique contrairement à ce qu'écrit Tanguy.

En moins lié au formatage physique. TeX permet surtout de produire des trucs comme DVI, PS et PDF, très liés au format imprimé sur des pages de papier. Troff permet de produire du HTML.

Plutôt pas d'accord: certaines personnes préfèrent utiliser groff pour écrire des maths aujourd'hui plutôt que TeX, car le premier leur donne un bien meilleur contrôle sur le placement des symboles dans les équations: la réalisation d'une typographie soignée proche du papier est une fonction importante de groff.

Ok, comme le html, docbook ou markdown

Tout faux. Ce que tu cites sont des langages décrivant des structures de document: on décrit un document par sa sémantique. Alors que groff est un langage décrivant l'aspect d'un document, c'est le genre de choses qu'il faut coller au bout de docbook pour obtenir un vrai document qu'on peut lire.

Bien-sûr, comme pour TeX, comme groff est programmable on peut l'utiliser à travers des macros permettant une description sémantique du texte. Mais il ne fait pas se tromper, groff et TeX sont des machines à écrire de luxe.

Et TeX et groff ont toutes les raisons du monde d'exister parceque pour réaliser des documents à la typographie compliquée, html, docbook et markdown sont complètement inutiles. Sans compter les mégaoctets de documents qu'ils permettent de préparer.

utilisé essentiellement pour les pages de manuels, qui utilise un formatage physique direct plutôt que des styles logiques

Les pages de manuel écrites avec groff_mdoc(7) utilisent des styles logiques, et c'est la grosse majorité des pages de manuel.

le gras est obtenu en faisant suivre chaque lettre par un retour arrière puis un second exemplaire d'elle-même, et le soulignement en faisant suivre chaque lettre par un retour arrière puis un tiret bas

En fait c'est beaucoup plus riche que ça, puisque les codes de contrôle ANSI sont utilisés par certaines version pour obtenir des vraies italiques ou des couleurs (le support dépend bien-sûr du terminal). Je ne sais pas comment le faire, mais je l'ai déjà vu, promis, juré.

On peut demander à less d'interpréter différemment ces codes de contrôle, je recopie la documentation des options -r et -R (à afficher en cinémascope ☺):

-r or --raw-control-chars
       Causes "raw" control characters to be displayed.  The default is
       to  display  control  characters  using  the caret notation; for
       example, a control-A (octal 001) is displayed as "^A".  Warning:
       when the -r option is used, less cannot keep track of the actual
       appearance of the screen (since this depends on how  the  screen
       responds to each type of control character).  Thus, various dis-
       play problems may result, such as long lines being split in  the
       wrong place.

-R or --RAW-CONTROL-CHARS
       Like  -r,  but  only ANSI "color" escape sequences are output in
       "raw" form.  Unlike -r, the screen appearance is maintained cor-
       rectly  in  most  cases.   ANSI  "color"  escape  sequences  are
       sequences of the form:

            ESC [ ... m

       where the "..." is zero or more color  specification  characters
       For  the  purpose  of  keeping  track of screen appearance, ANSI
       color escape sequences are assumed to not move the cursor.   You
       can  make less think that characters other than "m" can end ANSI
       color escape  sequences  by  setting  the  environment  variable
       LESSANSIENDCHARS to the list of characters which can end a color
       escape sequence.  And you can make less  think  that  characters
       other  than the standard ones may appear between the ESC and the
       m by setting the environment variable  LESSANSIMIDCHARS  to  the

Le mérite n'existe pas vraiment.

C'est tellement absurde de dire ça.

Sans dire que le mérite individuel n'existe pas on peut dire qu'il est assez difficile à reconnaître et que l'attribution de médailles jette dans l'ombre une vérité essentielle: les progrès en mathématiques ne sont que rarement (jamais?) le fait d'une seule personne mais plutôt d'un groupe de personnes ou d'une génération ou même de plusieurs générations de mathématiciens¹.

Nier la réalité des mérites individuels n'est pas plus ridicule que de nier l'importance des mérites collectifs, et si on peut dire que l'attribution d'une médaille n'est qu'un détail, l'époque actuelle est plutôt prisonnière d'une l'illusion surestimant les mérites individuels, dans les modes de recrutement comme dans les récompenses, la gestion des carrières ou les politiques de recherche.

¹ L'exemple typique que tout le monde connaît est la formalisation de l'algèbre linéaire. C'est de loin l'avancée la plus importante de tous les temps (pas facile de trouver un livre de maths sans algèbre linéaire aujourd'hui, hors certaines specialités très spéciales) et pourtant, à qui l'attribuer? C'est une avancée collective. Pour des problématiques plus actuelles comme le programme du modèle minimal, c'est encore tout à fait vrai.

Puis bureau de base ça veut pas forcément dire bureau pour un utilisateur de base car un utilisateur de base n'installera certainement pas une debian seul.

C'est un excellent point, qui rend d'ailleurs tout le reste de la discussion un peu HS puisqu'on peut choisir l'environnement de bureau à installer avec Debian — s'il ne faut en avoir qu'un, on peut probablement en installer plusieurs.

Ça me fait penser qu'on a jamais revu les deux types qui devaient passer entre les tours à la fin de leur formation…

En fait il veut dire que tu peut tester chaque méthode séparément, parce qu'elles ont des entrées et des sorties bien définies (tu peut forger les entrées de tes fonctions).

C'est exactement ca.

Cette organisation permet aussi de creer facilement les tests unitaires, en comparant avec diff la sortie attendue de la sortie produite.

Pour le debuging de script shell, l'option -x est utile sans être génial.

C'est exactement ca. :-)

Elle sert surtout a deboguer les utilisations de eval et les remplacements (string interpolation), mais si on a besoin de plus que "jeter un coup d'oeil" il vaut mieux ecrire un petit test unitaire.

Tu penses "etre clair = je peux le comprendre sans connaitre" et si ca ne t'interesse pas d'essayer de discuter ce point et que tu preferes le tenir pour acquis et continuer balancer tes jugements a l'emporte-piece, je te propose qu'on arrete de faire chier tout le monde ici et qu'on se connecte sur le canal de discussion approprie:

telnet localhost echo

On n'a pas la même façon de voir clair…

C'est clair quand tout ce qui a du sens est mis en avant et que l'accessoire est laisse derriere, que la structure est simple a changer, etc.

Penser qu'un programme est clair lorsqu'il est a peu pres comprehensible par quelqu'un ne comprenant pas le langage n'a rien a voir avec la clarte mais avec d'autres qualites du langage --- et surtout cela fournit une definition dependant de l'observateur, le genre de definitions pas super utile.

La version awk dit: decoupe chaque ligne d'input selon les /, et ecrit la ligne d'input suivie de | suivie de l'avant-dernier field suivi de / suivi du dernier field.

La version java est plus embrouillee (getName, c'est du babillage administratif, i.e. du bruit).

Il y a quand même pleins de façon plus lisibles de faire ça :

Effectivement la version awk est la mieux, et c'est la seule qui est vraiment tres claire et tres concise.

Le shell n'est pas moderne, c'est un fait. Par contre du cote de la lisibilite, les deux fonctions principales du shell sont

a. executer un programme, disons prog, cela ce fait en ecrivant

prog

b. faire traiter la sortie d'un programme par un autre, disons prog1 et prog2, cela se fait en ecrivant

prog1 | prog2

On peut dire que les concepteurs ont fait l'effort de rendre les deux fonctions principales plutot claires et lisibles.

Ensuite une propriete importante pour la clarte est

c. les fonctions definies par l'utilisateur ont (autant que possible) le meme statut que les programmes externes, c'est-a-dire qu'on les appelle de la meme facon et qu'on peut les combiner avec le pipe.

Et a, b, c, et bien il y a environ 0 autres langages de programmation mainstream qui le permettent.

Donc on fait on peut surtout conclure, qu'aucune des alternatives proposant 1, 2, 3 n'a reussi a s'imposer (l'exemple majeur etant tcl, cf. http://wiki.tcl.tk/17419) et que le shell reste le standard de facto en la matiere.

Ce serait effectivement dommage de realiser que le langage ou le traitement fait avec sed s'exprime clairement n'existe pas.

M'en fou : tu dis que c'est lisible, je te répond que non (suffit de regarder la commande sed…)

Je te dis que c'est lisible, j'argumente. Tu reponds non en donnant de mauvais arguments, car la commande sed n'est pas le shell et n'a rien a voir avec.

Mais bon, moi je m'en fous je n'ai rien a prouver a personne et si tu veux continuer a vivre enferme dans des prejuges superficiels, je ne perds rien.

Tu évites soigneusement de parler de l'imbitabilité de ta commande sed…

Pour la bonne raison que ca n'a rien a voir avec la programmation en shell.

Si la commande sed ne te plait pas, tu peux en utiliser une autre.

Peut-être, mais pour le moment je vois plutôt de la magie noire, vu que c'est illisible (surtout, ne pas mettre de commentaires sur ce que fait le sed…)

Le programme est construit en utilisant le pattern query/joblist/process qui est a peu pres la seule un peu exotique qu'il faut comprendre quand on fait du shell. Je vais donc detailler un peu.

Le shell est fort pour lancer des processus et aigiuiller les donnees entre differents processus. C'est donc sous la forme de donnees transitant entre des processus --- ou meme de fichiers --- qu'il faut representer toutes les donnees complexes.

1. backup_query genere la liste des sujets du script, les git repositories qui vont etre archives. Cela produit une liste

$basedir/johnuser/project.git
$basedir/alice/project.git
$basedir/alice/perso.git

1. backup_joblist prepare la liste des choses a faire et transforme la liste precedente en

$basedir/johnuser/project.git|johnuser-project.git
$basedir/alice/project.git|alice-project.git
$basedir/alice/perso.git|alice-perso.git

1. backup_process traite la joblist precedemment cree.

Le point clef est le point 2, que beaucoup de programmeurs traitent maladroitement en essayant de representer la joblist dans des variables du shell --- peche mortel!

En plus c'est tres facile a developper et deboguer car on peut facilement isoler un element du pipe pour l'ausculter, faire du mocking (avec cat)…

C'est tres facile a faire evoluer, par exemple s'il faut adapter la methode de backup au sujet, on peut ajouter une colonne verbe dans la joblist, qui precise la methode a utiliser et faire le dispatch dans backup_process.

Tu as bien-sur raison, ce que je mettais en doute est le fait que systemd soit plus simple que le systeme d'init, en fournissant une experience de pensee (bien limitee).