Michaël a écrit 2935 commentaires

Que j'ai prise à mille-pour-cent au pied de la lettre! :)

Il y a peu de raisons valables pour mettre à jour, à part la sécurité, la compatibilité …

Pour la partie applicative je te suis totalement, mais lorsqu'on développe on n'a parfois pas trop le choix dans la version de la bibliothèque qu'on utilise – par exemple si l'upstream ne fait du support que pour la toute dernière version, ce qui est un pratique assez courante dans plein de petits projets. (Ou des fois, la seule raison c'est que le chef le dit!)

PS : c'est quoi les PPA ? un truc dont j'ai jamais eu besoin ? :-)

Un PPA est une personal package archive. Ce sont des dépôts de paquets personnels, qui permettent de distribuer facilement des paquets non intégrés aux dépôts personnels. Par exemple dans le mien il y a des paquets pour Ubuntu de quelques logiciels que j'écris. L'intérêt est de pouvoir accéder rapidement à des mises à jours ou à des versions de développement si on en a besoin.

Coté technique, on prépare un paquet source qu'on upload sur une ferme de compilation avec dput et les gentils robots préparent les paquets binaires. (Mhh, probablement encore un mauvais tour de systemd cette histoire de paquets binaires.)

Même si ce n'est pas le nom d'un modèle particulier mais d'une famille de processeurs, ce serait sympa d'ajouter les neural net CPUs.

D'après ce que j'ai entendu, le Z80 et le MC68000 ont en commun de travailler par mi-mots.

D'ailleurs l'affectation se disait let on pouvait donc écrire mi-mot let … =.

Et d'un point de vue maintenabilité et facilité d'accés à la chose pour le reste de l'équipe le grep velu, ça vend pas du rêve.

Oui, et ça coule un peu de source: grep est un outil généraliste, donc dans un cas particulier il est forcément moins bon que l'outil spécialisé – si l'outil spécialisé ne fait pas mieux que le généraliste, il ne sert à rien! Et c'est le point clef de la discussion: pour plein de gens qui n'ont pas besoin spécialisés, les outils généralistes font un travail acceptable et peuvent être utilisés dans d'autres contextes.

Bien que certaines personnes veuillent la pousser dans cette direction, il ne s'agit pas d'une guerre de religion binaire contre texte, il s'agit simplement d'observer que pour la plupart des utilisateurs sans besoin particulier un outil généraliste fiat bien l'affaire et compense ses défauts de performance par… sa généralité. Bien-sûr que les spécialistes ont des besoins et des outils spécialisés!

par défaut windows il peut pas faire grand chose.

Tu peux discuter avec un trombone animé, ce n'est pas négligeable quand-même!

Que ça te plaise ou pas, le "texte" n'est qu'un format binaire comme un autre,

Il ne dit pas que ça ne lui plaît pas. Il dit que c'est vrai, et qu'on n'en a rien à faire parceque ça n'aide personne à travailler avec de les voir de cette façon. Je n'ai pas vraiment besoin de faire la liste de tous les outils qui travaillent sur des fichiers textes et qui ne servent pratiquement à rien sur des fichiers binaires généraux, si?

Tes arguments sur les métadonnées, etc. concernent la pratique de l'utilisation des fichiers texte. La pratique de l'utilisation des formats binaires est-elle bien meilleure? Et bien non, ça dépend des gens qui les écrivent, et je n'ai aucune raison de penser que les gens qui écrivent des fichiers textes dans un format merdique deviennent propres et consciencieux en écrivant des fichiers binaires!

Il y a des formats industriels (par exemple ESRI Shapefile, pour les formats de données géographiques) qui sont binaire et dont une métadonnée cruciale pour leur interprétation est absente du fichier (le nom de la projection utilisée, qui sert à interpréter les coordonnées géographiques des éléments décrits par le fichier – du coup, en pratique on écrit souvent le nom de la projection dans le nom du fichier, super hein?).

Ensuite ta position tord un peu le cou à l'histoire, puisque les fichiers et protocoles textuels sont en fait une évolution des formats binaires: ils sont plus portables et plus robustes. (Sauf quand on fait bien son travail, dans ce cas ils sont juste pareil.) Tu parles d'évolution mais la phrase de Churchill “Un peuple qui oublie son passé se condamne à le revivre.” semble aussi adaptée!

Je pense que devant l'idée d'ouvrir le fichier avec le Notepad de Windows, cette suggestion ne résistera pas à l'épreuve de la simplicité.

Je trouve quand même rigolo cette tentative d'inverser la situation, où celui qui dit qu'il faut accepter les choses différentes (car le format binaire est ce qui est différent, ce qui est nouveau) se voit accusé de refuser la différence de la part de personnes rejetant les différences (les nouveautés).

En tout cas j'ai une vision différente de ce qu'est une phrase claire! :D

Qu'est-ce que tu veux faire sécher dans cette histoire? Je pense qu'on met le marc de café dans un sceau d'eau savonneuse et voilou! C'est apparemment la même chose que les savons à micro-billes mais avec du marc de café à la place des micro-billes.

Comme toi, j'aime systemd, j'aime les jounaux binaires, j'aime la manière facile d'interroger le journal binaire, et j'aime que la machine travaille pour moi.

La machine travaille pour toi ou pour ton patron?

Si tu apprends les outils d'analyse et de transformation des fichiers texte, tu peux réutiliser ces compétences de façon créative pour résoudre plein de problèmes, différents, sur toutes les données qui utilisent un format texte. (Il y a même des formats textuels d'image!)

Si tu apprends les outils d'analyse et de transformation des journaux binaires, et bien tu vas travailler plus vite sur tes journaux binaires et rien apprendre d'autre: j'ai du mal à trouver cette promesse très excitante, contrairement à la première!

C'est utile de mettre des journaux dans une base de données – ce dont parle l'auteur de ton article – mais ce n'est beaucoup plus utile qu'un format texte que dans des cas très spécialisés. Et dans mon expérience, l'information utile à écrire dans ma base de données ne résulte pas d'une traduction ligne à ligne des logs mais d'une analyse plus approfondie des logs.

Pas besoin de lire un livre en entier pour comprendre : le mode texte se lit avec n'importe quel éditeur de texte de n'importe quelle os sur n'importe quel système.

Je pense que l'intérêt du “tout texte” est aussi – et surtout – que les outils d'analyse et de transformation de texte peuvent être utilisés sur toute sorte de données. Du coup ça vaut vraiment le coup de les apprendre!

C'est en le lisant que j'ai notamment compris pourquoi le it's all text est quelque-chose d'intéressant. Je vous le recommande chaudement.

Pas besoin d'écrire tout un livre pour expliquer ça. Le point clef est que si toute donnée est du texte, alors lorsque j'apprends les outils qui travaillent sur du texte alors je peux travailler sur toute donnée, et donc quelque soit mon activité, je développe des compétences que je peux réutiliser pour mes autres activités.

Donc lorsque je résous un problème avec sed et awk pour convertir ma base de nucléotides du format que lit le logiciel A dans le format que lit le logiciel B, et bien je peux aider un copain mathématicien à transformer ses équations textuelles crachées par Maple dans un format que Macaulay2 comprend, le latiniste à reformater ses citations, l'historien à vérifier ses références bibliographiques. Juste parceque tout est partout du texte.

Si le binaire systemd pour lire les logs permet de faire des recherches complexes grâce à une structuration poussée du format et de présenter le résultat d'une manière claire, ça peut être considéré plus simple que d'avoir à utiliser grep au feeling…

Quels exemples de recherches complexes? Pour moi c'est un intérêt largement théorique dans un usage généraliste et pour un usage spécialisé soit le point de vue “base de données” est pertinent et donc autant ne pas s'arrêter à mi-chemin et tout mettre dans une vraie base de données, soit le point de vue “base de données” n'est pas pertinent et dans ce cas les recherches (pas assez) complexes n'apportent rien. Alors oui c'est un peu plus sympa de dire

logtool --from 2015-02-01T00:00:00.000Z --to 2015-02-01T00:00:00.000Z --originatingHost=spammer.com

que de dire

sed -n '/^2015-02-01T00:00:00.000Z/,/^2015-02-01T00:00:00.000Z/{/from spammer[.]com/p}' < logs

Mais c'est juste ça, un peu plus sympa, un peu plus rapide, et pas beaucoup plus sympa ou beaucoup plus rapide. Bien-sûr il faut connaître sed pour écrire le deuxième truc, mais:

1. Le principe d'UNIX de travailler avec des fichiers textes, c'est qu'on développe des compétences réutilisables qu'on peut utiliser créativement dans d'autres contextes, cet aspect disparaît avec un outil d'extraction spécialisé. C'est un inconvénient réel du format binaire.

2. Les gens qui ont entendu parlé d'Internet savent qu'ils ne sont pas tout seul et que trouver quelqu'un qui pourrait les aider à filtrer leur logs.

Je ne me pense pas supérieur aux autres, loin de là, mais je n'ai pas la bêtise de penser que des gens qui ont pensé, codé, maintenu en vie pendant de nombreuses année un système d'exploitation étaient plus crétins que le dernier péquin à la mode qui publie un logiciel.

Si ça reste comme c'est, c'est que les avantages apportés par le changement ne contrebalancent pas le coût du changement. Faut arrêter de prendre les gens pour des endives réfractaires et dogmatiques. La vraie raison au fait qu'on utilise toujours des logs en mode texte, c'est bêtement que ça marche suffisamment bien dans plein de cas et que les avantages apportés par le format binaire ne contrebalancent pas le coût du changement.

La réalité de la base de données est que, dans un usage généraliste, elle n'est que marginalement plus utile que des fichiers textes parcequ'il n'y a aucune raison au monde pour que la question qu'on se pose en examinant les logs soit facile à traduire en SQL – tenant compte du schéma utilisé, en plus. Typiquement si on se pose une question un peu compliquée, on recherche des suites d'évènements et il faut écrire un parser travaillant sur un langage dont chaque ligne de log – les évènements sont les léxèmes. Ici avoir les logs dans une base de données n'apporte absolument rien.

Dans certaines situations spécialisées[], la base de données va donner de bien meilleurs résultats, mais dans une utilisation *généraliste, elle n'apporte qu'un petit plus. Sélectionner les logs entre deux dates avec un SQL plutôt qu'avec un filtre sed ou afficher les requêtes venant d'une IP donnée avec SQL plutôt qu'avec awk est plus rapide et plus fiable, mais pas au point d'inciter tout le monde à stocker les logs dans une base de données.

[*] Par exemple la mienne. :D

Comment pourrais-je retrouver le package program-2.35 ?

De mémoire, les paquets restent un certain temps dans les dépôts et il y a de bonnes chances pour que tu puisses reconstruire le paquet à partir des sources.

De toutes façon je n'ai jamais eu le cas où je regrettais une version précédente d'un logiciel…

Moi ça m'est arrivé de temps en temps – ma solution consiste à restaurer un backup du système de fichiers, ce n'est pas très subtil mais c'est très facile, rapide et ça marche bien. :)

Mais si cette situation ne t'arrive pas à quoi bon ne pas tout mettre à jour? Moi, même avec ma connection à 800kB par seconde les jours de fête, ça ne me pose aucun problème.

Je pense pas en avoir l'utilité ! :)

Il va falloir changer tout ça! :D

Quelques remarques:

1. Tu ne sauvegardes pas les versions des paquets que tu upgrades, du coup si tu te dis “Aah ben non en fait je préférais celle d'avant…” tu dois chercher la version à la main. En fait ce serait même sûrement mieux de faire une photo des versions installées puis de tout mettre à jour automatiquement.

2. Tu peux aussi faire xargs apt-get -y install < packages.

3. Je ne vois ni Emacs ni Vim dans ta liste… fais-tu partie du tiers des français athées? :)

4. Je ne vois pas bmake ni BSD Owl Scripts dans ta liste! :)

Fedora

Et FreeBSD – mais bon ok, c'est pas Linux :D

PS. N'hésite pas à poser des questions si tu en as pendant ton test!

Intéressant, j'y jetterai un œil, même si j'ai un mauvais apriori des Makefile

Heu, et bien moi aussi… :D Make est très pertinents mais c'est assez bizarre comme façon de programmer par rapport au procédural du shell. En shell on décrit la grosse tache (Faruggia ou Chabat?) en termes de taches plus petites, mais en Makefile, tout est “local” on ne décrit que des petits traitements. Ce qui est important c'est qu'en Makefile on écrit un programme dont l'état est codé par le système de fichiers (pas le contenu des fichiers, mais plutôt les fichiers eux-mêmes).

Sans parler du fait qu'il y ait une différence syntaxique entre les divers caractères blancs,

Ce n'est pas très grave, tous les éditeurs sont au courant et puis aujourd'hui on sait qu'indenter le code avec des tabulations c'est mal, donc il n'y a pas trop de confusion possible. (Les TAB ça sert à créer des colonnes dans un tableau, indenter du code avec des TABs c'est comme créer un page vide à coups de RETURNs dans un traitement de texte.)

Je ne savais pas qu'il y avait tant de différences que ça.

Il y a des différences énaurmes: BSD est plus facile à programmer et mieux documenté, et il y a des examples de Makefiles complexes et lisibles.

c'est bon ça! concis! lisible! maintenable (à première vue du moins)!

Je te rassure, les macros derrière sont complètement illisibles. Ça reste de la programmation! :D Mais l'interface et propre, et c'est du Makefile donc c'est très facile à étendre avec des procédures personnelles – c'est l'intérêt d'utiliser make.

dans mon ancien taff, qui avait besoin de windows pour certains outils de traitement, on avait installé cygwin,

J'ai beaucoup utilisé Cygwin dans mon poste précédent et très franchement je ne suis même pas sûr que ce soit beaucoup plus rapide qu'une machine virtuelle VirtualBox – voire même pas plus rapide du tout si on utilise une machine virtuelle sans environnement graphique, en Headless avec connection SSH. Les avantages d'une machine virtuelle sont multiples: UNIX marche mieux, c'est plus facile d'avoir un environnement cohérent, la gestion des paquets est meilleure, etc.

Cygwin était très pertinent avant la démocratisation des machines virtuelles, mais est-ce encore le cas aujourd'hui?

As-tu essayé comme ça?

env -i HOME="${HOME}" x-terminal-emulator -e bash

Sinon, je remplacerais volontiers le bash par su - "${USER}" qui simule un nouveau login et utilise donc le bon shell.

Tu devrais regarder BSD Owl et sa fonction subshell:

% bmake subshell
===> Entering developper's subshell
…

Cela ouvre un shell pour le développeur qui fait une partie de ce que tu veux: le shell est attaché à la racine du projet et le macros make fournies dans BSD Owl s'en souviennent pour lire la configuration globale permanente dans Makefile.config — typiquement générée par ./configure — et les amendements locaux (i.e. non versionnés) et temporaires dans Makefile.local. Cela permet bien de définir les variables contrôlant le nombre de processus de compilation, etc…

Le but est bien d'ajouter une vision globale du projet au make typique qui se concentre sur les dossiers. Les fichiers que l'on écrit sont bien des simples Makefiles — c'est le but du projet: fournir un système de build solide qui se base sur un outil courant, make — la version BSD, pas GNU.

Tu peux regarder quelques exemples de projets (C, LaTeX, OCaml, shell) dans le dossier test. Pour prendre un projet complexe en C le fichier Makefile principal ressemble à:

PACKAGE= heat
VERSION= 0.1-current
OFFICER?= michipili@gmail.com
MODULE= langc.lib:librational
MODULE+= langc.lib:libfibonacci
MODULE+= langc.prog:goldenratio

.include "generic.project.mk"

qui indique deux bibliothèques et un programme les utilisant. Le fichier Makefile pour une bibliothèque ressemble à

LIBRARY= fibonacci
SRCS= fibonacci.h
SRCS+= fibonacci.c

.include "langc.lib.mk"

(Cela prépare même la page de man ! ☺)

Le fichier pour la compilation du programme est du même tonneau!

C'est porté sous Debian et Ubuntu (paquets non officiels mais il existent!), MacPorts et FreeBSD. J'espère que ça te plaira. Si tu as des questions n'hésite pas à me contacter sur le forum, l'issue tracker — ou par email si je ne réagit pas, il y a mon mail dans tous les fichiers ☺ — comme disent certains, c'est de la balounette en barre! ☺ Ça me fournirait un prétexte pour écrire des exemples plus détaillés pour le support du langage C — par exemple, et fermer les tickets correspondant!

Le projet Anvil est un exemple de petit projet utilisant ces macros.

Ça fait quelques mois que je ne me fais plus que du café à piston.

Hors-sujet pour hors-sujet, j'en profite pour raconter comment la cafetière à piston a changé ma façon… de faire la vaisselle! :D

Pour nettoyer un plat à gratin ou bien une poêle en fer, le grain de café est très efficace: légèrement abrasif tout en étant très doux! Accompagné d'un chiffon de vaisselle, c'est bien mieux que la paille de fer!

J'ai l'impression que tu es en train de dire que parce que des effets non inquiétants ont lieu, les effets inquiétants ne peuvent pas exister.

Non je ne dis pas cela, d'où cela peut-il bien sortir?