Moonz a écrit 3542 commentaires

Un développeur qui accpete un patch dans sa branche principale s'engage à maintenir le patch totue la vie du projet.

Un développeur qui supprime des fonctionnalités plus maintenues ça s’est jamais vu effectivement.

J’ai merdouillé effectivement, le script GreaseMonkey n’est pas le bon ni sur github ni sur mon serveur.

J’ai mis à jour sur mon serveur, essaie de le réinstaller et dis moi si tu as toujours des soucis : https://ks3098700.kimsufi.com/wkr/autofill.user.js

Pour changer l’URL de l’autofiller, tu as une entrée dans le menu du script (sous firefox : Tools > Greasemonkey > Raccourcis du script > Set address).

On va pas refaire le débat, mais tout ça nécessite de la structure, pas du binaire, et il est tout à faire possible de structurer du texte.

À part ça, il y en a plein.

Les arguments de ce lien ont déjà été discuté dans un précédent journal (ou dépêche ?). Rien de tout ça ne nécessite un format binaire.

Aucun problème pour signer du texte par exemple (GPG pour les mails ça marche très bien…)

Mais franchement, si tu me disais que la seule machine à ta disposition qui puisse lire les log journald c'est la machine qui les produit, parce que tu n'as rien installé pour ça ailleurs, je penserais que tu n'as sûrement rien installé non plus ailleurs pour lire les partitions de la machine Linux, du coup les logs textes n'y changeront rien.

Allons, un peu d’imagination :

• pour le cas dont tu parles : accès aux logs en NFS/Samba/SSH
• je veux faire un traitement non prévu par journalctl, il n’y a pas de lib pour mon langage de prédilection (et j’ai pas que ça à faire que de coder un binding)
• je veux faire un traitement non prévu par journalctl, c’est du quick&dirty, je connais par cœur la lib standard de mon langage de prédilection et ça me prendrait 3 fois plus de temps pour apprendre la lib spécifique journald (par opposé à : « ho tiens, c’est du JSON compressé en zlib, je pourrai faire ça les yeux fermés tout en étant complètement bourré)
• je veux intégrer ça dans ma solution d’analyse de logs maison mais mon patron a dit « pas de copyleft »

Alors oui, dans tout ces cas on peut faire autrement, non, ce n’est pas à 100% bloquant.

Maintenant j’aimerais qu’on me donne une bonne raison pour laquelle journald se passe des bienfaits d’être compatible de base avec les libs standards de tous les OS sur tous les langages. Une seule. Ensuite je me tais, promis.

Tu peux les lire d’une autre machine sous un autre OS à travers un montage réseau aussi. Je n’ai pas assez de recul pour juger si c’est très rare ou pas, mais en tout cas ça m’est déjà arrivé dans ma carrière qui n’est pourtant pas très longue.

Mais quel format n'est pas binaire, enfin ?!

soupir

Binaire comme opposé à textuel. Il faut que je définisse « format textuel » aussi ? Honnêtement je n’ai pas envie de réécrire un dictionnaire informatique pour le plaisir de la dispute. Ceux avec un strict minimum de bonne foi auront compris, ou alors on est pas de la même espèce et nos schéma de pensée sont tellement différents que ça sert à rien d’essayer de communiquer…

Par contre, dire que l'UTF-8, même limité aux logs, est moins rencontré que le format binaire de journald, j'aimerais savoir où je l'ai dit.

Je ne vois pas comment interpréter autrement la contradiction que tu m’as apporté ici. Mais je peux avoir mal compris, ça m’arrive aussi (souvent même).

Quand l'encodage UTF-8 a commencé à se démocratiser, combien ont hurlé que UTF-8, c'est pas assez répandu alors que l'ASCII, on peut le lire sur n'importe quelle machine qui nous tombe sous la main?

N’importe quelle machine qui peut lire de l’ASCII peut lire de l’UTF-8, sauf les caractères non-ASCII (mais comme de toute façon ils sont pas représentables OSEF). C’est d’ailleurs cette compatibilité qui a fait la force d’UTF-8 (au début UTF-16 était pas mal poussé et certains pensaient que UTF-8 serait là uniquement pour la transition, mais bizarrement personne n’en voulait…)

Tu mentionnes toute machine qui a moins de 10ans peut le lire. Je te parie que d'ici 10ans il n'existera aucune système sur lequel un lecteur de log journald ne sera pas disponible!

Les langages de programmation? Ils auront leur bibliothèque, tout comme ils ont tous une bibliothèque XML.

Je n’ai pas de boule de cristal, mais ça m’étonnerait énormément. Le format de journald est spécifique à :

• Un système (Linux)
• Un logiciel (journald)
• Un usage (les logs)

quel mainteneur d’une librairie standard d’un langage voudrait prendre du temps pour ça, honnêtement ? La seule raison pour laquelle le format de journald arriverait dans les librairies standard d’un langage serait que ce format soit universellement adopté, de Microsoft à Apple en passant par les BSD. Les chances pour que ça arrive sont proches de 0 à mon avis.

Faire du format binaire spécifique avait du sens quand les librairies standard des langages tendaient à être anémiques et n’apportaient pas grand chose de réutilisable à quelqu’un qui voulait définir un nouveau format. Aujourd’hui l’usage a changé : les librairies standards tendent à essayer de couvrir de plus en plus d’usages avec quelques formats génériques (JSON, XML, zlib) mais qui peuvent couvrir quasiment tous les besoins. Aujourd’hui avec la lib standard de Python je peux gérer facilement des web-services (99% sont en JSON ou XML), des documents bureautiques (les deux formats dominants, OOXML et ODF sont juste des fichiers zip contenant des fichiers XML), des logiciels (idem pour les .jar, .apk, .ipa ou les extensions Firefox). En fait, à part les fichiers multimedia (video/audio/image), à peu près tous les fichiers que je manipule au jour le jour sont facilement « scriptables » (i.e. lisibles facilement en quelques lignes de Python en utilisant juste les outils fournis par sa lib standard). Ce que je ne me prive pas de faire, du reste. Je parle de Python, mais ça s’applique dans à peu près tous les autres langages.

C’est en regard de ces faits là que quand je vois quelqu’un réinventer la roue avec un nouveau format binaire spécifique, je tique. Pourquoi refuser de s’appuyer sur la puissance des librairies standard des langages modernes ? Un nouveau format binaire spécifique en 2014, ça ne m’inspire qu’une chose : un type excentrique sur son îlot qui s’amuse à définir une nouvelle langue à partir d’un mélange d’elfique et de klingon.

Alors bien sûr on peut toujours arguer que tous les usages ne sont pas implémentables avec ces 2-3 formats génériques. Ce qui est parfaitement vrai : je vois mal réécrire InnoDB avec juste zlib+xml par exemple. Mais pour moi ça devrait rester l’exception, une exception soigneusement justifiée, et je n’ai jusqu’ici vu absolument aucun argument convainquant justifiant cette exception dans le cadre de journald.

Je peux lire de l’ext depuis BSD et Windows. Probablement OSX aussi.

Alors pourquoi viens-tu défendre Zenitram quand il vient dire « UTF-8 est un format binaire » ?

Je ne vois aucune condescendance.

Mon affirmation de base est que UTF-8 est universel, supporté de base dans tous les langages, OS et toolchains modernes. Et toi tu me réponds « yaka faire du format de journald un standard de fait tout aussi universel » ? Mais tu sais, « universel », ça ne se résume pas à « l’ensemble des distributions Linux qui ont adopté systemd » hein…

En manque d’arguments ?

Tu as totalement raison : quand on me prétend qu’UTF-8 est un format binaire et est moins universel que le format binaire spécifique de journalctl, j’ai tendance à avoir du mal à trouver quoi répondre. Bon, c’est surtout que lorsqu’on arrive à un tel niveau de mauvaise foi, je considère que c’est pas la peine de me fatiguer à essayer d’argumenter proprement…

UTF-8 (un nouveau format binaire)

Tu cherches à entrer dans le livre guinness des records, section mauvaise foi, c’est ça ?

On remplace ça par un autre standard de fait (le format de fichier des logs de journald)

Bonne chance pour l’imposer au reste du monde informatique, on te regarde de loin et on en reparle quand tu auras réussi :)

Heu, il y a des équivalents de cat et de less (dont j’ai oublié le nom) dans les OS Microsoft depuis MS-DOS 6.0 hein…

Tu m’expliques l’intérêt pour FreeBSD, Apple, Microsoft, SunOracle… d’intégrer j* dans leur OS ?

Et bien entendu le monde se limite aux distributions Linux récentes.

(note aux mal-comprenants : le mot clef est « Linux », pas « récentes »)

Ça ok, mais de là à dire qu'un format "binaire" (par opposition au "format texte") est forcément complexe, quand on voit le bordel des encodages de texte, faut arrêter… C'est surtout là où je voulais en venir.

Il faut arrêter la fumette (ou la mauvaise foi) parfois. Le standard de fait aujourd’hui c’est utf-8. On parle de journald là, un outil moderne, pas du problème des encodages sur les systèmes antédiluviens qui font tout par défaut en EBCDIC.

Aujourd’hui, quelque chose « encodé » en UTF-8 est universel, lisible par tous les systèmes qui ont moins de 10 ans, supporté par absolument tous les langages et tous les outils vaguement maintenus. Prétendre le contraire c’est juste un gros troll même pas drôle.

Le mot-clef est « grande échelle », pas « outil ».

Mais une fois que systemd aura dominé le reste du monde ce ne sera plus vrai…

Et comme systemd n’a aucune intention de sortir de Linux, ce ne sera jamais vrai :)

Tu t’énerves pour rien, ce n’est pas très bon pour la santé. Personne ne remet en cause la pertinence de journald, seulement le choix d’un format binaire pour l’implémentation.

ou une mauvaise version de lib

Tu as déjà entendu parler de busybox ?

Tu n’as rien compris à la problématique.

Le problème de systemd n’est pas qu’il existe et qu’il soit là par défaut, mais qu’il prédate complètement la concurrence présente et surtout à venir.

Sans systemd (init), pas de udev, pas de logind, et probablement pas de wayland. Il est là le souci. Je cite Lennart :

I have serious doubts that Canonical will play catch-up with this so quickly. The last time they tried that they took logind out of the systemd tree and ported it to Upstart. logind of course is one of the components of systemd where we explicitly documented that it is not a component you can rip out of systemd. And of course, just a few months after Canonical did this, things are broken again, and this was to be expected: logind now uses the new cgroups userspace APIs (as mentioned above), and hence it will not run without systemd around. So Ubuntu is stuck with an old and unsupported version of logind. If they advocate this as a solution, then they are in ignorance onthat what they have is already out-of-date. (And yeah, this matters, for example all the nifty stuff that allows Wayland to run nicely without privs is implemented in the newer logind versions, and not in Canonical's forked version).

Il parle de Upstart vs systemd mais c’est bien le principe général qui fait couler tant d’encre : si tu veux pourvoir implémenter un concurrent à systemd, tu seras incompatible avec le reste du monde. Ce n’est pas le cas actuellement : il y a deux ans encore j’avais des systèmes sous initng ; Pardus a fait des trucs très intéressants dans son système d’init. systemd est en train de coupler très fortement des composants du système qui n’étaient pas couplés.

Le débat n’est pas un débat technique systemd vs sysvinit, c’est un débat politique entre monoculture et diversité.

Pourquoi faire ? Hors ligne, tu peux utiliser KeePass, puisque c’est le même format (si j’ai bien suivi)

Vu la puissance de calcul disponible sur nos machines, il est important d'inciter les utilisateurs à générer des mots de passes forts

Quelqu’un qui est intéressé par gPass/LastPass/WKR est à priori déjà sensibilisé au problème je pense. En pratique je ne vois pas vraiment l’intérêt de recoder ça dans le navigateur quand un pwgen -y 15 fait la même chose.