Bonjour cher 'nal,
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.
Faire des regex, c'est long, pas lisible, et chiant. La machine peut faire ça pour moi.
Chercher un symbole avec less, c'est pas pratique quand y'a des doublons.
grep n'est pas pratique sur un grand fichier, et multiplier les fichiers journaux c'est franchement pas génial pour avoir une organisation de ces fichiers bien rangée.
Oh miracle cher 'nal ! Quelqu'un pense comme moi et explique tout ceci et bien plus de manière bien plus détaillée et argumentée que je ne pourrais le faire. Quelqu'un qui utilise des journaux au format binaire depuis bien avant systemd-journald, et sans l'aide de systemd-journald.
Et comme une traduction pourrait dénaturer le propos, je ne propose que les liens :
Grepping logs is terrible
Grepping logs is still terrible
Bonne lecture !
# coquilles
Posté par xcomcmdr . Évalué à 1.
s/journals/journaux
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: coquilles
Posté par Benoît Sibaud (site web personnel) . Évalué à 2.
Corrigé, merci.
[^] # Re: coquilles
Posté par flan (site web personnel) . Évalué à 3.
s%fichier large%gros fichier%
(enfin, je pense)
[^] # Re: coquilles
Posté par tyoup . Évalué à 2.
Qui est gros ? Je ne suis pas gros, juste un peu enveloppé.
[^] # Re: coquilles
Posté par Thomas Douillard . Évalué à 5.
[^] # Re: coquilles
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
# Un couteau, c'est versatile
Posté par Xinfe (site web personnel) . Évalué à 10.
J'aime beaucoup ce qu'il raconte. En effet, un couteau peut servir à beaucoup de chose, mais ça reste beaucoup plus facile et rapide de se raser avec un rasoir et d'utiliser le couteau pour se beurrer des tartines.
Je me suis souvent retrouvé devant des outils super pratiques et puissants mais simplement chiants à utiliser car il faut apprendre en détail comment le faire fonctionner. C'est d'ailleurs pour ça que je préfère
egàman: la plupart du temps, je veux faire une opération simple sans prise de tête, du genre (dé)compresser une archive tar. Ou chercher des infos dans des logs un peu au petit bonheur la chance.Vivent les outils qui bossent à la place de l'utilisateur. Un bon sysadmin est un sysadmin fainéant !
[^] # Re: Un couteau, c'est versatile
Posté par Jiehong (site web personnel) . Évalué à 6.
C'est cool ce
eg! Merci bien ![^] # Re: Un couteau, c'est versatile
Posté par Sathors . Évalué à 2.
Question qui pourrait sembler bête, mais c'est quoi cet
eg?Sur une Linux Mint 13
egsemble faire référence àeasygit.Et bien sûr si je fais une recherche Google™ sur "eg", il me sort pleins de bêtises (toutes les pages qui ont "e.g.").
[^] # Re: Un couteau, c'est versatile
Posté par Julien.D . Évalué à 7.
Eg est un utilitaire qui indique quelques exemples d'usages courants d'une commande donnée.
[^] # Re: Un couteau, c'est versatile
Posté par Sathors . Évalué à 2.
Merci pour la réactivité.
En effet, ça risque de bien m'aider également !
[^] # Re: Un couteau, c'est versatile
Posté par Nairwolf . Évalué à 4.
Sinon, il y a aussi l'utilitaire cheat qui est plutôt sympa, et qui semble faire la même chose.
Vous trouverez plus d'info ici : http://www.gizeek.com/2014/10/28/cheat-noubliez-plus-vos-commandes-linux/
[^] # Re: Un couteau, c'est versatile
Posté par dinomasque . Évalué à 10.
J'aurais aimé avoir eg à la fac quand j'apprenais UNIX. Enfin GNU plutôt qui a des pages de manuel pas géniales car dénuées d'exemples (c'est mieu fourni chez BSD)
BeOS le faisait il y a 20 ans !
# Mais systemd le fait mal
Posté par louiz’ (site web personnel) . Évalué à 5.
Je veux bien, mais systemd doit mal se démerder alors, parce que j’ai jamais vu un truc aussi lent que journalctl.
Quand il lui faut plusieurs minutes pour afficher une centaine de lignes (alors qu’avec tail et grep ça prend une demie seconde), je me demande un peu comment ils s’y prennent.
[^] # Re: Mais systemd le fait mal
Posté par Jiehong (site web personnel) . Évalué à 8.
T'as peut-être un souci, car chez moi c'est instantané.
[^] # Re: Mais systemd le fait mal
Posté par louiz’ (site web personnel) . Évalué à 4.
(Inutile de préciser qu’avec cat, ça prend 0.029 seconde)
Je suis en ext4, et j’ai jamais entendu quelqu’un dire que journalctl était pas lent chez lui…
[^] # Re: Mais systemd le fait mal
Posté par Zenitram (site web personnel) . Évalué à 10.
Comment te croire? Le commentaire auquel tu réponds te fait mentir…
[^] # Re: Mais systemd le fait mal
Posté par Moonz . Évalué à -8.
Et tu n’as pas dit ça à Jiehong parce que ?…
C’est rigolo ces préjugés que tu as sur un système que tu n’utilises même pas.
[^] # Re: Mais systemd le fait mal
Posté par Zenitram (site web personnel) . Évalué à -4. Dernière modification le 07 mai 2015 à 20:06.
Pas compris :
- Jiehong a dit "jamais"? Je cherche encore, j'ai vu "peut-être" qui n'a rien à voir. A-t-il remit en cause le fait que le problème existe chez l'autre? Je n'ai pas lu ça.
- Où est le préjugé dans une test booléen? tu dis que 1 est inférieur ou égal à 0, tu as une façon de faire des maths que je n'ai pas appris à l'école. Le fait que je n'utilise pas X n'a aucune incidence sur la notion de "jamais" qui n'accepte pas le nombre 1, enfin… J'ai appris à l'école un truc genre chercher à savoir les paramètres qui influent, et ceux qui sont neutres.
Dit-moi, par curiosité, comment tu peux croire une personne qui dit "je n'ai jamais vu personne qui soit noir, impossible à croire que ça existe" en face d'une personne qui est noire?
Bref, c'est rigolo les attaques envers des personnes qui ne te plaisent pas, sans réfléchir 2 secondes, ça en devient ridicule.
[^] # Re: Mais systemd le fait mal
Posté par Marotte ⛧ . Évalué à 10.
Mais parce que Jiehong dis juste deux choses : peut-être tu as un souci et chez lui ça fonctionne.
Toi tu dis : « j’ai jamais entendu quelqu’un dire que journalctl était pas lent chez lui… »
Des points de suspension on déduit que tu sous-entends que c'est lent chez tout le monde, ça c'est une chose, mais Zenitram pointait surtout le fait que tu ne peux pas dire que tu n'as jamais entendu quelqu'un ne pas se plaindre alors que justement Jiehong te dis qu'il n'a pas à se plaindre, avoue que c'est cocasse, surtout pour un Zenitram assez à cheval sur le respect de la logique.
J'ajouterais qu'à ma connaissance il n'utilise pas GNU/Linux sur son desktop mais il administre des serveurs sous GNU/Linux pour vivre. Enfin c'est en tous cas ce que j'ai cru comprendre, je ne le connais pas personnellement.
En fait, tu aurais dû préciser : « j’ai jamais entendu quelqu’un à part toi dire que journalctl était pas lent chez lui… », Zenitram n'aurait pas bronché et moi j'aurais pas perdu 5 minutes à écrire ce commentaire :)
[^] # Re: Mais systemd le fait mal
Posté par louiz’ (site web personnel) . Évalué à 7.
J’adore ce quiproquo géant, c’est fascinant.
Non, moonz n’a pas dit ça, c’est moi qui l’ai dit.
(même remarque pour tout le reste du message du coup, tu t’adresses à moonz comme si c’était moi, c’est très drôle mais du coup on comprend plus grand chose)
Comme je l’ai répondu à deux autres endroits : oui, ayez un peu de bon sens.
[^] # Re: Mais systemd le fait mal
Posté par groumly . Évalué à 4.
Probablement parce que repondre "j'ai jamais entendu dire que journalctl etait pas lent" a un mec qui vient de dire "chez moi journactl est pas lent", c'est un peu chelou quand meme.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Mais systemd le fait mal
Posté par louiz’ (site web personnel) . Évalué à 2.
Évidemment que je voulais dire « à part toi » (ou « avant toi »).
Ayez un peu de jugeotte s’il vous plait…
[^] # Re: Mais systemd le fait mal
Posté par Zenitram (site web personnel) . Évalué à 0. Dernière modification le 08 mai 2015 à 08:08.
Toi, tu dois être celui qui a créé les pubs qui contiennent le mot "illimité" que tout le monde ayant "un peu de jugeotte" comprendra évidement comme "limité"…
[^] # Re: Mais systemd le fait mal
Posté par louiz’ (site web personnel) . Évalué à -3.
Non
[^] # Re: Mais systemd le fait mal
Posté par louiz’ (site web personnel) . Évalué à 2.
Oui, avant lui, évidemment.
[^] # Re: Mais systemd le fait mal
Posté par 2PetitsVerres . Évalué à 9.
Ben il ne l'a pas entendu, à moins d'utiliser de la synthèse vocale pour surfer sur DLFP.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Mais systemd le fait mal
Posté par louiz’ (site web personnel) . Évalué à 3.
Non mais il doit être du genre à comprendre « entendu » dans le sens « entendu, ou lu » (ce qui est plutôt bien vu, étant donné que c’est ce qu’il fallait comprendre).
Par contre quand il faut comprendre « jamais, sauf toi, évidemment, vu que tu viens de le dire », là il comprend pas.
Il a de la jugeotte que quand ça l’arrange.
[^] # Re: Mais systemd le fait mal
Posté par Jiehong (site web personnel) . Évalué à 3.
J'ai pas autant de logs que toi, mais avec 10 % de tes logs, j'ai ça :
En supposant que ce serait linéaire, j'obtiendrais
0,249 × 213361 ÷ 18719 = 2,838secondes. Ça me paraît pas trop mal.Tu peux aussi restreindre la sortie de journalctl au boot actuel avec
-b, ce qui limite les lignes inutiles, et sera plus rapide.[^] # Re: Mais systemd le fait mal
Posté par louiz’ (site web personnel) . Évalué à 5.
Ah ouais, moi ça me parait ridiculement lent. C’est donc pour ça que l’un dit « chez moi ça va » et l’autre dit « chez moi ça va pas ».
[^] # Re: Mais systemd le fait mal
Posté par tatrefthekiller . Évalué à 7. Dernière modification le 08 mai 2015 à 02:51.
Je trouve ça ridicule aussi :-)
Chez moi, pour un log de 170.000 lignes (25 Mo), ça met 3s avec journalctl, sur de l'ext4 sur un SSD, mais de toutes façons c'est côté CPU que ça pèche.
Au taff, je manipules des logs de plusieurs centaines de Mo, voir plusieurs Go avec cat, grep, sed… et tout est quasi instantanné.
[^] # Re: Mais systemd le fait mal
Posté par Guillaume Rossignol . Évalué à 3.
Je suis quand même dubitatif sur ces problemes de temps d'execution. Typiquement au boulot, une partie des logs est centralisée, parsée et consultée par le trio «elasticseearch/logstash/kibana» et d'autres non.
Alors effectivement le resultat d'un grep est plus rapide que d'aller faire la recherche dans kibana. Mais la confiance que j'ai dans une regex que j'ai ecrits pour répondre à un besoin bien particulier est bien moindre qu'une recherche dans kibana avec des logs correctement parsés.
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.
Mon avis personnel, c'est que si on a besoin d'aller voir quelque chose régulierement sur une machine, autant faire en sorte que ce soit la machine qui nous envoit l'info., Pour les cas exceptionnels, finalement, mettre 0.1s ou 3s à attendre un resultat ne change pas forcement grand chose (surtout qu'il faut aussi compter le temps d'ecrire la regex qui ne va pas sortir une tonne de resultat tout en étant sur d'avoir toutes les lignes pertinnentes)
[^] # Re: Mais systemd le fait mal
Posté par Michaël (site web personnel) . Évalué à 5.
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!
[^] # Re: Mais systemd le fait mal
Posté par Benoît Sibaud (site web personnel) . Évalué à 7.
Valable aussi dans l'autre sens : j'ai des besoins spécialisés (je veux chercher des choses compliquées mais jamais les mêmes) mais ils varient souvent. J'utilise un outil généraliste que je maîtrise (plusieurs même, combinés à grands coups de pipe) pour obtenir un résultat spécialisé. Cela n'est possible que parce que je suis devenu un « spécialiste en outils généralistes », que je peux contorsionner à ma guise, alors qu'un utilisateur veut en général un outil qui marche directement et simplement, donc plutôt un outil spécialisé, pas un couteau suisse dont il faut lire le man et éviter les parties tranchantes. Au bout d'un moment (peut-être est-ce déjà le cas), de meilleurs outils généralistes ou spécialistes existeront et rendront plus ou moins obsolètes ma connaissance du manuel de sed/awk/cut/paste/grep/uniq/sort/etc et des regexps. Mais il y a toujours besoin de spécialistes et de généralistes, aussi bien chez les personnes que chez les outils.
[^] # Re: Mais systemd le fait mal
Posté par claudex . Évalué à 6.
J'ai un peu du mal à comprendre cette opposition généraliste/spécialiste, typiquement avec journald, j'utilise les deux. Je filtre rapidement sur des champs particuliers (nom d'unités, date, criticité) et ensuite (si ça ramène trop de ligne), je filtre avec grep/awk/uniq/… ça me permet d'éviter des regexp compliquées tout en gardant la puissance des outils généralistes.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Mais systemd le fait mal
Posté par lockidor . Évalué à 3.
Je ne sais pas si c'est le même problème, mais
systemctl status SERVICEmets aussi plusieurs secondes pour afficher les dernières lignes de log chez moi. D'autres ont le même souci ?[^] # Re: Mais systemd le fait mal
Posté par xcomcmdr . Évalué à 1.
chez moi c'est instantané.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Mais systemd le fait mal
Posté par Jiehong (site web personnel) . Évalué à 2.
J'ai pas le souci (c'est près de 100 × plus rapide).
Mais c'est peut-être lié, en effet.
J'ai limité la taille des logs à 100 Mio dans
journald.conf, et si tu n'as pas besoin de tant de journaux, c'est peut-être une bonne idée de changer la taille par défaut (10 % de la taille de la partition, variableSystemMaxUse).As-tu regardé la taille de ton
/var/log/journalpar hasard ?Avec une limite à 100 Mio, j'ai mes journaux système depuis le 5 novembre 2014, et potentiellement pour plus longtemps (machine de bureau).
[^] # Re: Mais systemd le fait mal
Posté par louiz’ (site web personnel) . Évalué à 2.
Si, c’est le même souci, vu qu’il va chercher les n dernières lignes de log
systemctl status nginx 0.00s user 0.02s system 1% cpu 1.341 total
[^] # Re: Mais systemd le fait mal
Posté par Albert_ . Évalué à 1.
Question:
quel distrib utilises tu?
[^] # Re: Mais systemd le fait mal
Posté par needs . Évalué à 1.
Oui chez moi c'est la même, sur Archlinux. Quand exécute deux fois de suite la commande par contre elle met moins de temps. Enfin ça dépend, car
netctl statusc'est toujours très lent. Une histoire de cache de fichier ou je ne sais quoi…[^] # Re: Mais systemd le fait mal
Posté par Jiehong (site web personnel) . Évalué à 4.
Wow ! C'est vraiment super lent.
Je viens d'essayer, et j'obtiens ça la première fois (zsh) :
Je suis aussi sous Archlinux, mais là ça me paraît vraiment bizarre que ça soit aussi lent chez toi pour un service inactif. Chez moi, c'est une partition Btrfs. J'ai testé avec
bash, mais c'est quasiment identique (pour avoir la même commandetimeque toi).[^] # Re: Mais systemd le fait mal
Posté par needs . Évalué à 1.
Si tu as un SSD ça peut jouer, sinon le noyau avait déjà toutes les informations dans son cache de fichier. Voici ce que j'ai après deux exécutions :
Enfin bon c'est pas très grave…
[^] # Re: Mais systemd le fait mal
Posté par louiz’ (site web personnel) . Évalué à 5.
11 secondes pour voir le statut d’un service, moi je trouve ça quand même vachement gênant…
[^] # Re: Mais systemd le fait mal
Posté par Jérôme FIX (site web personnel) . Évalué à 2.
Vous auriez pas un soucis de config quelque part quand même ?
time systemctl status nginx
● nginx.service - A high performance web server and a reverse proxy server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
Active: active (running) since lun. 2015-05-11 20:33:35 CEST; 24h ago
Main PID: 10101 (nginx)
CGroup: /system.slice/nginx.service
├─10101 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
├─10102 nginx: worker process
├─10103 nginx: worker process
├─10104 nginx: worker process
└─10105 nginx: worker process
systemctl status nginx 0,00s user 0,00s system 0% cpu 0,017 total
J'ai un SSD mais ma machine est loin d’être un foudre de guerre !
[^] # Re: Mais systemd le fait mal
Posté par louiz’ (site web personnel) . Évalué à 4.
C’est la conf par défaut, ça a toujours été comme ça, et
j’ai jamais entendu quelqu’un dire qu…avant ce topic ici-même je ne connaissais personne chez qui journalctl n’est pas incroyablement lent.Et je te laisse
googlerduckduckgoer (quel nom à la con, quand même…) "journalctl slow" pour te convaincre que c’est fréquent.Allez, pour la route, une discussion sur la ML officielle http://lists.freedesktop.org/archives/systemd-devel/2013-October/013513.html
Et aucune proposition de solution en vue.
[^] # Re: Mais systemd le fait mal
Posté par needs . Évalué à 2.
La messe est dite.
[^] # Re: Mais systemd le fait mal
Posté par claudex . Évalué à 3. Dernière modification le 15 mai 2015 à 23:23.
Sur mon serveur web, avec des disques durs. Par contre, c'est de l'ext4, pas du btrfs pas prêt.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Mais systemd le fait mal
Posté par Moonz . Évalué à 3.
Si tu es en btrfs, passe le dossier de logs en ext (ou désactive le COW sur ce dossier)
[^] # Re: Mais systemd le fait mal
Posté par Mildred (site web personnel) . Évalué à 2.
C'est une solution que j'avais vu, mais ça ne marche pas forcément. J'ai passé progressivement mes machines de btrfs a ext4 justement a cause de ce problème, et de temps en temps, il revient me mordre.
C'est pas un problème de fs, c'est plus que ça.
Et si on fait pas gaffe, ça peut t'empêcher le boot complètement. Solution: exécuter le kernel avec init=/bin/sh et virer le dossier de logs journald.
Avec une conf de base non modifiée, Fedora ou ArchLinux.
[^] # Re: Mais systemd le fait mal
Posté par Mildred (site web personnel) . Évalué à 2.
C'est exact, j'ai souvent le même problème. La solution c'est de supprimer l'archivage des logs sur le disque (enlever
/var/log/journald). C'est dommage, car journald offre tout de même plein de fonctions sympa. Mais il y a un réel problème de performances, qui m'a souvent empêché ou ralentit le boot de manière considérable.Et pourtant, je ne suis pas vraiment anti systemd. J'ai switché de ArchLinux à Fedora a l'époque où systemd démarrait, juste pour l'utiliser.
# Je sais qu’on est vendredi mais…
Posté par Moonz . Évalué à 10.
Même pour un vendredi c’est quand même trop gros.
Sur regexp texte vs querying :
Ce n’est pas une opposition binaire vs texte, c’est une opposition structuré vs non structuré.
Tu peux très bien avoir du binaire non structuré : schématiquement
write(logFd, &logEntry, sizeof(logEntry))(où LogEntry est une structure non documentée, non standardisée, variant d’un logiciel à l’autre et même d’une version à l’autre). Et dans cette situation, bonne chance pour « avoir la machine qui fait des regexp pour toi ».Tu peux très bien avoir du texte structuré : JSON + json-schema, XML par exemple. Et dans ce cas tu peux avoir les mêmes outils d’aide à la recherche.
Sur le reste, je vais pas répondre point par point. Il suffit de regarder le début du billet pour voir où est le gros problème dans l’argumentattion :
Cette liste de requirements, ce n’est pas de l’écriture de logs, c’est de la gestion de base de données tout ce qu’il y a de plus classique ! De fait, journald ne fait pas le quart de ce qui est décrit dans cette liste. De fait,
Je ne vois pas en quoi c’est de « l’abus », au vu de la liste. Le workflow qu’il décrit pour son système :
c’est exactement le workflow d’un développeur SQL.
On en vient au problème fondamental de l’article : cette méthode d’utilisation des logs, c’est '''une''' méthode d’utilisation des logs, pas '''la''' méthode d’utilisation des logs. Tout le monde ne traite pas ses logs comme une base de données à usage quotidien. C’est un usage totalement valide (dans quelques années dans ma boite, qui sait ? Mais actuellement non), mais c’est un usage spécifique, qui nécessite des outils spécifiques. Tu ne peux pas passer à cette liste de besoins à une conclusion type « c’est LA méthode de gestion de logs ». Un autre usage des logs, totalement valide, c’est un truc qu’on met de côté et qu’on ne ressort qu’en cas de problème pour savoir ce qu’il s’est passé. Et dans cette situation un grep global sur tout le log est infiniment plus pratique qu’un schéma structuré, si tu n’as qu’une poignée d’indices, sans parler de l’efficacité (on a pas à mettre en place tout ce process extraction-stockage-indexation juste pour aller inspecter les logs tous les 36 du mois).
Il y aurait encore plus à dire sur certains point de détails (le requêtage c’est bien gentil, mais encore faut-il savoir quoi requêter et comment, et la réponse est loin d’être triviale si tu n’as pas beaucoup réfléchi en amont à ta structure), mais j’ai assez nourri le troll pour le moment.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Je sais qu’on est vendredi mais…
Posté par flan (site web personnel) . Évalué à 2.
Question bête pour la structuration des données.
Est-ce qu'une bête base de données SQL classique (sqlite quand on est en local, ou pgsql/mysql si on veut faire plus compliqué) ne pourrait pas convenir ? Quel est l'intérêt d'un format binaire spécifique alors que du SQlite dispose déjà de milliards d'outils ?
[^] # Re: Je sais qu’on est vendredi mais…
Posté par groumly . Évalué à 3.
La rigidite du schema.
Un truc comme logstash/elastic search, et j'imagine journald (quoque j'ai pas verifie pour etre honnete) te permet d'indexer ce que tu veux comme tu veux, et c'est plutot pratique quand tu recois des logs divers et varies qui ont un nombre arbitraires de champs.
Les donnees sont aussi pas relationnelles du tout, t'auras typiquement une table monstrueuse avec aucune relation/contrainte.
Tu peux eviter la rigidite avec une rdb qui supporte le json (genre postgres), mais on en droit de questionner la pertinence du relationel pour stocker du pur document, sans compter que pg va pas etre jouasse si tu fais que des requete sur le contenu du json. Un format dedie te permet d'extraire l'index en dehors de la partie donnees.
L'idee etant j'imagine que c'est cense marcher aussi bien sur la machine de tata jeanine que sur un container chez facebook qui va se prendre 200 requetes/secondes (encore qu'eux balancent tres probablement leur logs en remote et ont autre chose a foutre que de grepper vm par vm).
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Je sais qu’on est vendredi mais…
Posté par Firwen (site web personnel) . Évalué à 5.
Exactement, sans compter que tu apporterais en prime tous les problèmes bien connus depuis 20 ans qui affectent les DB relationels et qui a été à l'origine des mouvements NoSQL des dernières années: problème de scalabilité horizontale, localité, throughput, replications..
La système de gestions des logs s'apparentent bien plus à un data warehouse + analytics ( on stock tout, on remonte les éléments important, et aprés on analyse en différé) que d'une base de donnée relationel ( où on structure/process/index en temps réel pour rester consistent ).
Ce n'est pas pour rien que toute les infras de logs modernes s'orientent vers une architecture type rsyslog/journald + logstash + elasticsearch avec souvent un stockage des données brute.
Ça a beaucoup d'avantage :
- Distribué orienté message passing => ça scale
- On garde les logs brutes, ce qui autorise à réinterpréter les données quand c'est nécessaire
- Ça donne une grande flexibilité sur le schéma des données.
- On a à la fois les avantages du format texte (les données brutes) et du binaires (les index).
Utiliser une DB relationnel pour faire du stockage de log, c'est plus ou moins utiliser un couteau suisse pour couper un arbre: Ça marchera oui, mais c'est pas pour rien qu'on a inventé la tronçonneuse :D
[^] # Re: Je sais qu’on est vendredi mais…
Posté par briaeros007 . Évalué à 1.
Tout le contraire : logstash tu as besoin de connaitre les champs poru que ce soit utile.
et EL c'est juste un moteur d'indexation, et indexer tout une ligne de log ne sert strictement à rien, il faut indexer les champs.
Et si tu as des messages non connu avec des champs inconnu au moment de la mise en palce de l'infra, ben logstash+EL mettra bien plus de temps qu'un grep sur des fichiers log.
Enfin, il a parlé de "sql", mais "sql" ne veut pas dire rdb, et je pense qu'il parlait juste "base de donnée" (et je te l'accorde, une no-sql est bien adapté pour la gestion de log correctement taggée).
[^] # Re: Je sais qu’on est vendredi mais…
Posté par Misc (site web personnel) . Évalué à 1.
Parce que sqlite est monoprocessus, dans mon souvenir ( à l'époque du lancement de trac, ce qui remonte ).
Si tu écrit, tu lis pas. Mais on m'a dit que ça a finalement changé, donc peut être que je me trompe.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Je sais qu’on est vendredi mais…
Posté par Antoine . Évalué à 1.
Cette page ne dit pas si on peut faire des lectures et écritures concurrentes. C'est le sens de la question originale, car si une recherche de 10 secondes sur une grosse base de logs bloque l'ajout de nouvelles entrées de logs, ça fait une belle jambe de savoir que deux processus peuvent se connecter à la base de données.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1. Dernière modification le 11 mai 2015 à 19:07.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Je sais qu’on est vendredi mais…
Posté par Sufflope (site web personnel) . Évalué à 7.
C'est marrant parce qu'il démonte ta remarque à 3 endroits différents dans ses 2 articles mais visiblement c'était pas assez. Je vais tenter de réussir là où il a échoué.
Il ne prétend pas que des logs binaires sont la solution à toutes les situations, il souhaite qu'on arrête de lui dire que ça n'est jamais adapté dans quelque cas que ce soit.
En donnant notamment son workflow où du texte brut ne convient pas. Et en mettant double dose de moquerie sur les mecs qui hurlent sur journald qui stock des logs binaires… en proposant à la place de les stocker dans un mysql qui c'est bien connu utilise des fichiers texte dans /var/log.
[^] # Re: Je sais qu’on est vendredi mais…
Posté par Moonz . Évalué à -1.
Et pourtant, dès l’introduction :
Ici il ne dit pas « le binaire est meilleur pour mon usage » (ce que pas grand monde n’a contesté ici, il me semble), il dit « le binaire est meilleur », point.
[^] # Re: Je sais qu’on est vendredi mais…
Posté par flan (site web personnel) . Évalué à 5.
Non, il dit « il y a vraiment peu de raisons d'utiliser un stockage texte quand il y a une meilleure option disponible »
Traduction : quand le binaire est meilleur, il ne voit pas de raison d'utiliser du texte.
[^] # Re: Je sais qu’on est vendredi mais…
Posté par groumly . Évalué à 5. Dernière modification le 09 mai 2015 à 11:11.
C'est une facon polie de dire que le texte brut n'est jamais utile.
Tout son argumentaire tourne autour de ca.
Edit: le titre est explicite quand meme "grepping logs is terrible"…
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Je sais qu’on est vendredi mais…
Posté par Misc (site web personnel) . Évalué à 3.
Non, parfois deployer une machinerie complexe style ELK, Graylog, splunk n'est pas une meilleur option si ça te rajoute juste du taf sans rajouter des fonctions significativement requises.
L'admin sys, c'est pas gratuit, et je pense qu'il faut prendre sa remarque dans cet optique aussi.
[^] # Re: Je sais qu’on est vendredi mais…
Posté par Sufflope (site web personnel) . Évalué à 10.
Non, il dit "il y a peu de cas où le texte est meilleur" et, autant j'admets que ça va au-delà du point que j'essaie de réhabiliter dans le message auquel tu réponds ("arrêtez de me dire que le binaire n'est jamais bien"), autant je suis assez d'accord avec lui.
Mais on est d'accord qu'on débat au delà du problème "certains prétendent que les logs binaires sont une hérésie en toute circonstance (mais recommandent mysql pour stocker leurs logs text") ?
Pour mon boulot actuel (une appli web), on a peu de visiteurs quotidiens (on est pas Facebook et en fait on essaie pas de l'être) et pourtant les logs textuels syslogs standards sont une putain de plaie. Suivre une session d'un visiteur web sur plusieurs frontaux à travers apache/tomcat c'est juste infaisable avec grep. C'est tout. Si, pardon, c'est faisable. A condition de sacrifier une moitié de couverture capillaire par utilisation. Donc, vu que j'essaie de pas finir chauve, j'ai testé une fois et maintenant je sauvegarde ma moitié de cheveux restants en ne faisant plus la même connerie.
Alors sur DLFP évidemment on est dans un univers parallèle où l'expert (haha) moyen gère au choix lui-même en autohébergement, ou 2 clients qui se battent en duel dans sa SSLL à l'agonie. Là, ouais, un bon vieux /var/log/messages ça suffit, de toute façon s'il y a un réel problème non décrit sur howtoforge.org il met la clé sous la porte.
Dans la réalité les logs se séparent en deux parties, les logs client de la debian sid du geek moyen dont on se branle carrément (et le texte c'est bien, enfin /dev/null aussi), et les logs d'un vrai business où sans un outil un miminum intelligent genre graylog ou splunk t'arrives à rien (et donc t'es bien plus dépendant que d'un simple format binaire…)
[^] # Re: Je sais qu’on est vendredi mais…
Posté par briaeros007 . Évalué à 3.
Salut,
tu correlles comment tes utilisateurs sur tes différents serveurs ?
Tu as résolu comment ton problème de risque capillaire ? (ca m'intéresse :) )
Cordialement
[^] # Re: Je sais qu’on est vendredi mais…
Posté par Sufflope (site web personnel) . Évalué à 2.
C'est pas moi le devops donc je vais ptêtre me gourer, mais on utilise graylog2 (ça je suis sûr) pour centralisation/consultation/alertes et logstash (là j'ai un doute) pour la tokenisation des logs sur chaque machine. Comme ça dans graylog2 on peut chercher par exemple par ID de session ou login ou…. comme je disais on a peu de trafic donc on a pas passé des mois non plus à faire un truc super complexe.
[^] # Re: Je sais qu’on est vendredi mais…
Posté par wismerhill . Évalué à 2.
Avec MySQL, ça peut se faire :-)
http://dev.mysql.com/doc/refman/5.5/en/csv-storage-engine.html
# format standard / normalisation
Posté par goeb . Évalué à 1. Dernière modification le 07 mai 2015 à 21:07.
Est-ce qu'il y a une sorte de normalisation du format de log binaire ?
C'est quelque chose qui manquait au début des logs textuels, dont la seule normalisation tacite était que les logs étaient en caractères imprimables (visibles), et séparés par des retours à la ligne.
Et ce serait utile pour les logs binaires afin d'utiliser les mêmes outils d'analyse de logs partout.
[^] # Re: format standard / normalisation
Posté par Zenitram (site web personnel) . Évalué à 4.
http://www.freedesktop.org/wiki/Software/systemd/journal-files/
(façon classique des libristes de faire une norme = je tente un passage en force avec ma façon de voir, d'ailleurs on le voit on aimerait un format de package normalisé, rpm a été choisi avec LSB et tout le monde s'en fout)
Vu le nombre d'utilisateurs de systemd, je ne me fais pas de soucis, les outils d'analyse suivent ou suivront.
Et au pire, reste tes outils d'analyse pour les anciens log, ils marchent toujours au coût faible d'une ligne de commande et d'attendre un peu.
# Un peu de lecture
Posté par robin . Évalué à 6.
Salut à tous,
Je manque encore clairement de recul pour pouvoir troller allégrement dans la bataille binaire vs texte, mais j'ai presque finis de lire ce livre disponible librement sur Internet qui explique les principes fondamentaux d'UNIX. Il date de 2003, mais malgré ça il reste encore d'actualité. 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.
Sur ce, bonne lecture.
bépo powered
[^] # Re: Un peu de lecture
Posté par hervé Couvelard . Évalué à 9.
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.
Tu peux monter ton disque sur une autre machine, si tu as accès à ta partition, tu peux lire le log. Il est plus compliqué de lire un log binaire à un format particulier dont tu n'es pas spécialiste lorsque l'outil n'existe pas sur le système que tu utilises.
Exemple tout con, j'ai journal.truc.binaire sur mon serveur. il plante ou se fait véroller, mon prestataire me donne une "image" de ce qu'il était, il est fort peu probable que je puisse facilement trouver des infos dans les logs si je suis sous une distribution qui n'a pas (encore) systemd. Et même si j'ai systemd, je ne suis pas persuadé qu'il soit trivial de lire les logs d'une autre machine.
Et je ne parle même pas qu'il est impossible de perdre un fichier texte pour un soucis de corruption, au pire tu perds un ou deux caractères, tandis qu'une archive zip corrompu c'est déjà plus la merde pour récupérer un truc.
Parce que le merveilleux monde de bisounours ou tout le monde est à la dernière version sur tous ses postes, tous ses serveurs, avec la même distribution je l'ai pas vu en vrai. Mais je ne connais pas tout le monde dans le monde il est vrai.
De même pour le tout est fichier, il est tellement simple de faire cat /dev/input/whatever pour voir que la souris est bien mappée ou on l'attend.
Maintenant je ne dis pas que c'est la seule bonne manière de faire, mais je trouve que ce n'est pas une mauvaise manière et elle a ses avantages. Il faut bien réfléchir à se passer de ces avantages pour en donner d'autres à la place.
Faudra voir avec le temps, il est tellement simple de dire TAKAFAIR comme ça avec cette commande magique, on ne le saura qu'avec le recul. Il suffit de se souvenir de toutes ses merveilleuses technos qui allaient révolutionner ta user expérience et qui n'existent plus : celui qui s'est investi dessus, il a un peu perdu de son temps.
[^] # Re: Un peu de lecture
Posté par groumly . Évalué à 5.
Tu rotate pas tes logs, ni ne les compresse?
Un zip bousille est pas tellement plus utile qu'un binaire journald corrompu. Alors certes, t'as le fichier de log, courant, mais a ce compte la, autant tailer stdout, ca revient au meme.
Apres, si tu parles de desktop, si t'as souvent besoin d'aller fouiller dans tes logs, le probleme c'est pas tant le systeme de logs que le desktop qui visiblement ne marche pas franchement comme il devrait.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Un peu de lecture
Posté par Zenitram (site web personnel) . Évalué à -9. Dernière modification le 08 mai 2015 à 07:47.
Attend, elle est très rigolote ta phrase.
Réutilisons-la :
le mode journald-file se lit avec n'importe quel éditeur de journald-file de n'importe quelle os sur n'importe quel système.
Ha oui, ça marche aussi.
Merci pour la démonstration.
Conneries : tu as besoin d'un éditeur (ou lecteur) journald-file, comme tu as besoin d'un éditeur (ou lecteur) texte sur ta distro.
Et celui qui n'a pas investi sur la bonne techno parmi les technos qui ont arrété, il fait faillite. Rappel : systemd est sur toutes les distros majeures maintenant.
Alors la, c'est impressionnant une phrase aussi rigide et conservatrice…
On croirait que tu as été le PDG de Nokia (refus de voir le tactile arriver, car bon c'est encore une techno qui n'allait plus exister plus tard pas la peine d'investir dessus, et puis les gens ne sont pas habitués, ceux connaissant les touches auraient du mal à s'adapter).
Ou une personne à qui on a dit il y a 2000 ans "il ne faut pas faire x car y", y a disparu mais tu continues à ne pas faire x par habitude en disant que c'est horrible sinon.
Ou… Bon, trop d'exemples…
Ta façon d'argumenter a une conséquence très simple : interdiction de changer quoi que ce soit, on fige.
Désolé, certains ont une autre vision de la vie.
Sinon, avec ton super éditeur de texte, tu peux me dire ce que signifie la suite 11/12/13? 11 décembre ou 12 novembre? Ton éditeur le dit? Cool pour toi, mais d'autres ne savent pas (il faut des metadatas à côté pour dire quel est le "format" de la date).
Faudra arrêter de raconter les mêmes conneries sur les avantages des fichiers textes en ométant tous les défauts (la date n'est qu'un exemple parmi 36 autres formatages, ha les greps qui ne trouvent pas parce que le log est fait différemment genre un espace pas prévu par ta formule…)
Surtout, ne pas réfléchir au problème et faire le religieux qui va écouter son "mentor" (qui? auto-formation?) en (se) cachant les défauts et sans rien remettre en question.
PS : avant, je compressais mes logs. C'était mal car tu avais pas le décompresseur? Tu as toujours gardé en clair? Et si on te file une partition ext4 mais que ta distro ne gère que ext3, tu râles aussi et interdis ext4, toi tu es resté en ext1 c'est ça? bref, qu'est-ce que cet "argument" anti-systemd de base déjà démonté 36 fois peut être chiant à relire tellement c'est n'importe quoi et qu'il suffit de réfléchir un tout petit peu pour se dire que c'est comme il y a x années avec une autre techno… Ca évolue, et on peut évoluer avec, tout simplement.
PPS : j'ai un CD-Audio, mais tu as un lecteur K7 c'est ça, salauds qui ont changé le format pas lisible chez toi?
[^] # Re: Un peu de lecture
Posté par briaeros007 . Évalué à 6.
Tu me le donne le nom du "éditeur de journald-file" sur le poste bureautique windows de mon taff où je n'ai le droit de rien installé ?
[^] # Re: Un peu de lecture
Posté par xcomcmdr . Évalué à -1.
Tu lis des logs Linux sur un poste Windows où t'as aucun droit ?
C'est pas les fichiers binaires qui sont en cause, c'est tes méthodes de travail !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Un peu de lecture
Posté par briaeros007 . Évalué à 10.
et question idiote : tu ne recois jamais des logs par mail pour une aide sur un problème où tu n'as pas accès à la machine qui a généré les logs ?
moi si.
Désolé de ne pas avoir le même travail que toi.
Et sur un windows, je lis sans problème un fichier texte, et ca m'évite de la genuflexion sur les transfert de fichier vers des machines d'un autre niveau de sécu que mon poste bureautique (que je réserve sur les cas qui en vale la peine)
Je peux donc faire un premier tri rapide, donner une première analyse, sans me prendre le choux.
Mais comme je n'ai pas le même taff que toi, je présume que c'est la faute de mes "méthodes de travail", et pas ta grande ouverture d'esprit …
[^] # Re: Un peu de lecture
Posté par briaeros007 . Évalué à 1.
+5 pour une attaque personnelle sans argument.
-1 pour une réponse argumentée (mal peut être, mais j'ai essayé, et j'estime avoir été poli même si ma dernière phrase , il est vrai, est un peu sarcastique) .
Et ensuite on va expliquer que personne ne note sur le fait que le commentaire est pro-ceci ou anti-cela sur linuxfr .
Rien ne change ici, et ensuite c'est les même qui parlent d'évolution et de future : lol.
/me aimerais bien des discussion un peu dépassionné des fois. On pourrait certainement mieux se comprendre, et ça serait plus agréable je pense.
[^] # Re: Un peu de lecture
Posté par gnumdk (site web personnel) . Évalué à 5.
Le mec qui t'envoies un log par mail, il fait:
journalctl -R > mail.txt
[^] # Re: Un peu de lecture
Posté par Zenitram (site web personnel) . Évalué à -4.
Pas compris ta demande :
- On parle d'évolution, au début tu n'avais pas d'éditeur UTF-8 non plus, tu disais la même chose à l'époque? Si ça n'existe pas maintenant, comme pour UTF-8 on le créé quand besoin. Ca s'appelle l'évolution.
- droit d'installer != droit d’exécuter. On t'interdit aussi d’exécuter?
- Je n'ai pas dit que ça existe, j'ai juste repris sa phrase (qui ne parle pas d'existence), on peut parler de ce que je dis et non pas d'inventer? Ma critique est sur un sujet précis (sa façon de voir l'évolution), pas sur l'existence ou pas d'un logiciel.
[^] # Re: Un peu de lecture
Posté par briaeros007 . Évalué à 6.
désolé mais l'utf-8 je lis sur n'importe quel éditeur de texte.
UTF-16 je dirais pas, mais utf-8 je n'ai pas de souci pour avoir l'immense majorité des infos d'un fichier de log.
Quand à un poste "sécurisé", vi on m'interdit d'executer dans pas mal de cas, surtout sur un binaire non reconnu.
Enfin, pour reprendre : on a jamais parlé d'évolution : tu as dis que c'était aussi facile "yaka" prendre des logiciels qui existent partout.
Je te demande un logiciel pour un cas qui m'intéresse, et oh ca alors ce n'est plus aussi facile.
il y a vraiment un jour où il faudra que vous preniez en compte qu'il n'y a pas que votre façon de faire/de travailler qui existe de par le monde.
Et que même si vous estimez qu'elle est complètement idiote ou autre, certains sont quand même obligé/ont ces besoins.
[^] # Re: Un peu de lecture
Posté par Zenitram (site web personnel) . Évalué à -5. Dernière modification le 08 mai 2015 à 15:05.
Aujourd'hui, oui.
Pas hier.
Et aujourd'hui n'est que le hier de demain.
sans compter que personne ne me répond sur mon histoire de date… Alors, dans ce fichier texte, c'est quelle date 11/12/13?
En effet : il y a vraiment un jour où il faudra que vous preniez en compte que des gens souhaitent évoluer, et ne pas s'arrêter à Latin-1 parce que telle personne ne sait pas lire UTF-8.
Personne n'impose systemd, donc ben… n'utilise pas.
Et il faut commencer un jour quand on implémente UTF-8 (oui, ce genre de discours "pensez aux vieux" ne date pas d'hier, même pour les fichiers textes on a eu ça!)
Ca tombe bien, quand on arrête les conneries et qu'on se renseigne un peu, on trouve de suite l'option pour que systemd fasse une copie en mode texte pour ceux qui ont besoin de "legacy", comme on a fait des adaptateur DVI vers VGA à une époque (tiens, c'est un truc qu'il fallait interdire aussi que de faire du DVI? Ben oui, un adaptateur, quelle horreur!!!).
Ca ne pose aucun problème quand on ne veut pas juste haïr pour le plaisir ce qui évolue.
Sérieux, réfléchissez à ce que signifie à long terme votre façon de penser, et surtout réfléchissez à comment on fait les migrations depuis la naissance de l'informatique : votre "problème" n'a absolument rien de nouveau, et on a survécu. Pire : ce que vous avez chez vous aujourd'hui est disruptif par rapport à ce qu'il y avait avant, et vous n'auriez pas vos fichiers dans le format que vous aimez si on avait écouté les mêmes réactions à l'époque de la migration.
Bref, rien de nouveau.
[^] # Re: Un peu de lecture
Posté par briaeros007 . Évalué à 10.
mdr
t'es toujours aussi marrant quand tu t'énerve tout seul.
On parlait de la facilité de lecture d'un journal binaire, et tu nous fait un commentaire comme quoi systemd c'est génial et qu'on ne force personne à l'utiliser (ce qui soit dit en passant n'est pas tout à fait vrai).
Tu me sorti des argument, que j'ai retoquais pour mon cas particulier, et tu invente absolument n'importe quoi pour ne pas avoir "tort" (utf-8 a toujours été lisible avec un éditeur de texte quelconque. Il a été concu pour assurer une compatibilité avec l'ascii. Et les caractères spéciaux dans les logs représentent une fraction totalement négligeable de l'information…)
Le cout de la date, xptdr aussi. 0x813456 ca représente quelle date pour toi ?
Le problème de conformité, de format et de convention existe toujours quelque soit le formalisme des data.
continu de t'énerver tout seul et de faire de beau homme de paille pour troller et essayer de t'autojustifier.
Ps : tu parles d'évolution, de future … mais ton comportement il n'évolue pas lui, toujours aussi immature et impossible d'accepter la moindre idée et comportement différent de ton filtre binaire.
[^] # Re: Un peu de lecture
Posté par Zenitram (site web personnel) . Évalué à -5.
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).
Tant que vous y croyez vous même, ça doit suffire pour s'auto-persuader, en attendant Linux essaye d'avancer malgré les personnes refusant les comportements différents. Depuis la nuit des temps, les gens qui essayent d'évoluer doivent se battre contre les gens qui refusent la différence (mais la, c'est encore plus beau, les gens refusant la différence demande à ce qu'on accepte la différence, joli)
Mais j'avoue que c'est beau à voir des personnes refusant la différence demander à ce que les autres acceptent la différence.
Pour info, systemd exporte en texte pour les personnes "différentes" (bref, le legacy), et n'est imposé à personne.
[^] # Re: Un peu de lecture
Posté par Michaël (site web personnel) . Évalué à 5.
En tout cas j'ai une vision différente de ce qu'est une phrase claire! :D
[^] # Re: Un peu de lecture
Posté par Albert_ . Évalué à -1.
Je reve!!!! Tu es en train de te faire trucider sur systemd et on te fait passer pour un anti-systemd alors que … c'est l'inverse!!!! Tu es en train de parler de ce qui toi te parait comme problematique dans ton taff en relation avec cette techno et aussitot tu te fais demonter en categorise dans le camp adverse. Je n'ai qu'un seul mot "impressionant".
[^] # Re: Un peu de lecture
Posté par Moonz . Évalué à 5.
Hier aussi, en mode dégradé (où les caractères hors du range ASCII s’affichent mal mais le reste est OK).
Ça tombe bien, les caractères non ASCII dans les logs, c’est rare.
Si tu veux critiquer le mode texte sur la base de l’historique « ça a pas toujours été universel », tu peux citer la guerre EBCDIC/ASCII, mais il va falloir accepter qu’on te prenne pour un vieux crouton ensuite :)
[^] # Re: Un peu de lecture
Posté par groumly . Évalué à 8.
Les characteres non ascii sont rare, si t'operes en occident uniquement, certes. Mes logs d'asie/pacifique, ils sont pleins de characteres pas ascii du tout. Et aussi de characteres ascii, parce que mes messages a moi eux sont en anglais. En l'occurence, tout est en utf kekchose, donc on s'en cogne, mais les arguments "le texte est 100% universel", suivi de "nan, mais les bols de riz, les arabes et les feuj, on s'en branle", ca va 5 minutes (et desole pour les langues non latines que j'ai oublie).
Pour l'ebcdic, sans etre un crouton, je me suis bouffe du support ebcdic quand je bossais dans une boite qui gravitait autour du milieu bancaire. La encore - l'argument d'universalite du texte ne tient pas.
Et de toutes facons, l'argument est foireux en premier lieu, vu que tout le monde compresse les logs, tu finit avec du binaire meme si tu logge en plain text.
Et si tu compresses pas, va falloir soit se poser de serieuses question sur tes ops, soit tu logges pas, et la question ne se pose pas vraiment.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Un peu de lecture
Posté par Albert_ . Évalué à 0.
Mes logs d'asie/pacifique, ils sont pleins de characteres pas ascii du tout.
Bofff que ton editeur supporte ou pas le UTF-8 c'est tout de meme du chinois.
[^] # Re: Un peu de lecture
Posté par groumly . Évalué à 4.
du japonais en l'occurence. c'est nippon ni mauvais, pour être honnête.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Un peu de lecture
Posté par Albert_ . Évalué à -1.
Puti il y a (je ne parle pas pour toi) mais pour les moinsseurs:
Tu parles de langues asiatique et je fais une blague de potache sur le theme " c'est ecrit en chinois" vielle expression francaise. C'est assez amusant de voir cela :)
[^] # Re: Un peu de lecture
Posté par claudex . Évalué à 3.
Soit, il y a des gens qui ne savent pas formuler leurs blagues.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Un peu de lecture
Posté par Marotte ⛧ . Évalué à 3.
Tu bootes le liveUSB de n'importe quelle distribution systemd-aware, ça devrait le faire, non ?
===>[]
[^] # Re: Un peu de lecture
Posté par briaeros007 . Évalué à 3.
j'aimerais bien. Tu me file le mot de passe du bios ? Et non je ne peux pas modifier la pile ou autre.
[^] # Re: Un peu de lecture
Posté par groumly . Évalué à 3.
C'est pas la faute de systemd si tu bosses pour une boite qui t'empeche activement de faire tom boulot non plus,
Si tu fais du support pour linux et qu'ils t'interdisent d'installer les outils linux necessaires a ton taff, comment dire?
Va gueuler aupres de ton boss plutot qu'ici.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Un peu de lecture
Posté par briaeros007 . Évalué à 5.
où j'ai parlé de "faute" ?
J'ai juste parlé sur le fait que les journaux binaire , non ce n'est pas la panacée absolue, et non ce n'est pas aussi facilement utilisable qu'un simple fichier texte.
Maintenant vous ne voulez pas entendre et continuez à croire que les journaux binaire c'est le monde des bisounours, grand bien vous fait.
<3615 ma vie>
Moi perso , chez moi j'ai désactivé systemd car un système d'init qui se met en vrac sur un fstab fonctionnelle mais avec une partoche totalement optionnelle qui ne monte pas ca ne convient pas à mon besoin, ni à ma vision de la résiliience nécessaire pour un tel logiciel.
Ensuite si systemd est parfait pour toi, tant mieux tu pourras profiter de tous ses ajouts.
</3615>
Je vous demande juste d'accepter qu'on a pas tous les mêmes besoins et utilisations, et que certains peuvent apporter un éclairage différents sur certaines technologies.
Ca ne veut pas dire que votre, ou mon, opinion est mauvaise, juste différente.
[^] # Re: Un peu de lecture
Posté par groumly . Évalué à 1.
et moi je te demande d'accepter que le besoin que tu as cite au dessus n'est pas raisonnable.
Idem avec ton délire de Red Hat 6.7 sans acces internet.
Sinon, tu t'énerves vachement pour un mec qui souhaite un débat dépassionné.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Un peu de lecture
Posté par briaeros007 . Évalué à 2.
Non raisonnable?
Mais pourquoi donc "non raisonnable". C'est un peu court comme argument, ca ressemble plus à un jugement qu'un argument.
Perso je n'aurai pas l'audace de juger de ton protocole de travail comme "raisonnable" ou "non raisonnable".
Quand on travaille en entreprise un tant soit peu sécurisé ou industriel, il y a des protocoles et des contraintes sur ce qu'on peut installer et inter-connecter.
Cela me semblait être suffisament connu pour ne pas avoir besoin de l'indiquer.
Je vois pas où je suis énervé. Je répond juste, de façon je crois poli, et j'essaie d'apporter des faits et des arguments plutôt que des jugements.
[^] # Re: Un peu de lecture
Posté par groumly . Évalué à 1. Dernière modification le 09 mai 2015 à 11:20.
Faire du support linux sous windows, c'est pas raisonable, systemd ou pas. Tu peux blablater ce que tu veux, c'est un use case a la con.
Et il y a aussi des protocoles pour changer ce qui est installe. Et accessoirement, travailler en entreprise un tant soit peu securise ne veut pas necessairement dire avoir des admins nazis
En l'occurence, si c'est rigide que ca chez toi, tes produits ne supportent probablement pas systemd de facon officielle, et donc le probleme ne se pose pas.
D'ou delire, et besoin non raisonnable.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Un peu de lecture
Posté par briaeros007 . Évalué à 5.
Je te laisse donc à ton ouverture d'esprit et ta vision réaliste du travail dans les "grosses" boites avec des gestions centralisées.
[^] # Re: Un peu de lecture
Posté par gnumdk (site web personnel) . Évalué à 4.
Moi je comprend pas vraiment ton délire, l'entreprise ou les admins sont sous Windows, elle active rsyslog sur les serveurs et demande à journald de forwarder les logs…
[^] # Re: Un peu de lecture
Posté par brendel . Évalué à 1.
Y'a un point quelque chose quand on en vient à dire que les besoins des gens sont débiles quand ils s'adaptent pas au produit? Parce que c'est le moment où l'argumentation devient vraiment inexistante. (Surtout quand on parle de 3 secondes gagné au boot comme un besoin utile, on évite de juger ceux des autres. /troll)
[^] # Re: Un peu de lecture
Posté par Zenitram (site web personnel) . Évalué à 2.
Cette discussion tourne en rond :
- soit il y a un besoin de lire les logs journald sous Windows et dans ce cas une personne sur 6 milliard d'humains va pondre en 2 jours max (à lire la spec, ce n'est vraiment pas bien compliqué)
- soit il y a en fait personne qui ose avoir besoin de lire les logs journald sous Windows et on s'en fout
Bref, en pratique ça montre surtout que les gens qui doivent "subir" journald n'ont pas vraiment de problèmes avec lui pour le lire, c'est un non problème juste pour le plaisir de râler, on leur ferait le logiciel gratos qu'ils trouveraient un autre problème.
[^] # Re: Un peu de lecture
Posté par claudex . Évalué à 4.
Et il y a le code existant de disponible, même s'il faut l'adapter pour qu'il fonctionne sous Windows. (peut-être même qu'il y a moyen de le compiler sous cygwin mais je ne m'y lancerait pas)
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Un peu de lecture
Posté par briaeros007 . Évalué à 1.
ps : j'avais pas vu la dernière phrase.
Désolé si tu penses que je "gueule". Je ne le fais pas.
Je répondais juste au message de zenitram qui disait que c'était super facile de lire les journaux de logs binaires , et ce n'importe où.
BRef, que la lecture d'une journal binaire était aussi facile qu'un journal en mode texte.
J'ai donc pris un cas réel pour montrer que malgré sa volontée manifeste que tout se déroule parfaitement partout, ce n'était pas le cas, en lui soumettant un cas où la lecture du journal textuel se faisait sans trop de soucis, mais que la lecture d'un journal au format bien spécifique, et assez peu répandu en dehors de certains cas.
J'aurais , si je voulais m'amuser, pu aussi demander sur un RHEL 6.7 sur un réseau indépendant (pas connecté à internet) avec juste les dépots redhat officiel (level 1, car bien que je soit à peu près sur qu'il n'y ait pas le soft daans les dépots rhel de base on est jamais à l'abri d'une bonne surprise)
Et en level 2 : même question mais avec une freebsd 6 :P
Et on serait arriver sans trop de mal à la même conclusion.
[^] # Re: Un peu de lecture
Posté par Zenitram (site web personnel) . Évalué à -3.
Je demande une preuve de ce que tu dis.
Tu torts les commentaires que tu n'aimes pas pour qu'il correspondent à ce que tu veux lire.
Toujours aussi marrant les anti-systemd (car ce n'est que ça, finalement) à devoir inventer pour s'auto-convaincre que c'est si horrible.
[^] # Re: Un peu de lecture
Posté par briaeros007 . Évalué à 2.
Tu me l'avais pas encore faite celle là.
Tu n'apporte aucune preuve, tu modifie tous les commentaires , réponds sans aucun arguments autre que tes affirmations vides, et maintenant tu demandes des "preuves" et surtout sans préciser sur quoi tu aimerais ta preuve (sinon ça serait trop facile de répondre, je risquerais de t'apporter ce que tu demandes).
Ensuite tu explique que ton adversaire est très méchant, tu le range dans une catégorie pour dire "vous voyez il est comme ça il est méchant".
Bon si tu lisais correctement, tu verrais que je ne suis pas anti-systemd, et que je reste objectif : systemd ca a des avantages … et des inconvénients.
J'ai testé (la preuve que je ne suis pas contre) et j'ai eu ma propre opinion. JE comprends très bien qu'il convienne à certain avec les avantages qu'il apporte, mais il ne me convient pas.Point.
Mais pouvoir constater deux faces d'une même pièce doit avoir saturer ton système de réthorique et tu as donc conserver que la moitié de mes propos dans ta ram :)
[^] # Re: Un peu de lecture
Posté par brendel . Évalué à 6. Dernière modification le 11 mai 2015 à 16:55.
Venant de toi, elle est un peu grosse celle la non? Cette phrase décris a peu près chaqun de tes commentaires.
De même tu parles toujours de stats sans aucunes sources et tu demandes une preuve? On pourrait parler de l'hopitale qui se fou de la charité mais ici on parle plutot de poutre je crois.
[^] # Re: Un peu de lecture
Posté par Michaël (site web personnel) . Évalué à 3.
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é.
[^] # Re: Un peu de lecture
Posté par Zenitram (site web personnel) . Évalué à -1.
On parie? je peux te filer un fichier texte qui ne sera sans doute pas lisible chez toi, tu changeras alors ton point de vue sur le sujet?
(je sais pas, tellement de choix : en UTF-32LE par exemple, si tu as un système trop évolué et qu'il supporte déjà UTF-8, ou je peux inventer mon propre codepage aussi pour le fun, ce sera toujours un format texte, mais ce format texte sera du binaire que tu ne comprendras pas, normal car le texte n'est que du binaire avec un format précis sur lequel tu t'es mis d'accord avec ton expéditeur…)
Penser que le format texte est universel, c'est oublier l'histoire (et même le présent).
[^] # Re: Un peu de lecture
Posté par SlowBrain (site web personnel) . Évalué à 3.
Une seule solution : Imprimer en temps réel ces logs avec une bonne vielle imprimante a aiguille.
Bon, les datacenter vont avoir une tête bizarre, et c'est pas trés écologique, mais plus besoin d'outils compliqué pour savoir lire les logs.
[^] # Re: Un peu de lecture
Posté par Jiehong (site web personnel) . Évalué à 2.
Dans l'absolu, on peut lire n'importe quel fichier en mode binaire (via un éditeur hex par exemple), mais de là à le comprendre, c'est autre chose ^
Bon, mais tous ces formats c'est quand même bien la merde (par exemple, un fichier texte en chinois encodé en big5, et illisible en supposant que c'est de l'utf-8 par défaut).
[^] # Re: Un peu de lecture
Posté par hervé Couvelard . Évalué à 4.
donc il est plus compliqué de lire un UTF-32LE qu'un blob binaire fait avec un logiciel que tu ne connaitrais pas ?
[^] # Re: Un peu de lecture
Posté par Zenitram (site web personnel) . Évalué à -10. Dernière modification le 08 mai 2015 à 13:16.
Rassure-moi : tu le fais exprès?
Parce que c'est tellement énorme que je peux que penser ça.
[^] # Re: Un peu de lecture
Posté par hervé Couvelard . Évalué à 4.
ah et juste question subsidiaire, c'est quelle distribution qui code ses logs en UTF-32LE ?
[^] # Re: Un peu de lecture
Posté par Zenitram (site web personnel) . Évalué à -5. Dernière modification le 08 mai 2015 à 13:36.
Hors sujet : tu as dit "le mode texte se lit avec n'importe quel éditeur de texte de n'importe quelle os sur n'importe quel système." sans aucune exception.
Donc quelque soit le format des logs, dès que c'est taggué "texte", tu dois pouvoir le lire, tu l'affirmes.
Mais bon, si tu veux une réponse exacte dont on se fout car tu as dit n'importe quel : la mienne, c'est pas interdit, je l'ai créée ce matin. Voila, content? D'ailleurs, es-tu au courant qu'avant UTF-8 généralisé il y avait une vie avec des personnes détestant UTF-8?
C'est con, mais le format texte n'est pas si universel que tu le fantasmes… Et ça a fait suffisamment souffrir des développeurs (ha les changements de locales… et autres joyeusetés) pour que ces mêmes développeurs ne déteste pas le "binaire".
PS : alors, cette date en mode texte, tu sais laquelle est la bonne? Sérieusement, où est la mauvaise foi? La mauvaise foi est exactement le reproche que je fais au commentaire auquel je répond, à quoi ça sert d'inverser les critiques surtout sans démontrer? Désolé d'avoir démontré ta mauvaise foi
[^] # Re: Un peu de lecture
Posté par hervé Couvelard . Évalué à 8.
ok, il n'est pas si universel.
Maintenant que nous avons acté cela, est-il plus universel qu'un fichier binaire ou moins universel qu'un fichier binaire ?
Prenons un use case simple, je suis pas très intelligent :
Prenons un serveur de base, sous un linux quelconque, chez un hébergeur quelconque français.
Prenons un fichier de log de base fait par un serveur mail ou web.
Est-ce que je vais avoir un soucis pour le lire sous win98, winXP, vista, seven, huit, 10 ou sous macosx ou sous 95% des distributions linux ?
Prenons le même log fait par un logiciel qui écrit des logs en binaire dont tu as l'exécutable sur ton serveur,
Est-ce que je vais avoir un soucis pour le lire sous win98, winXP, vista, seven, huit, 10 ou sous macosx ou sous 95% des distributions linux ?
C'est JUSTE ce que ma réponse veut DIRE.
[^] # Re: Un peu de lecture
Posté par Zenitram (site web personnel) . Évalué à -7. Dernière modification le 08 mai 2015 à 14:06.
Ca dépend : si tu as la chance d'avoir un lecteur qui supporte le format du log "texte" de la distro.
En fait, ça dépend exactement de la même chose qu'avec le log binaire de systemd : il te faut un lecteur compatible.
Après, rigolo avec le format "texte" que tu aimes (celui qui par chance est créé par ta distro serveur et lisible par ta distro bureau), tu ne réponds pas à ma question sur la date, peut de comprendre que tu as quand même un soucis avec ton texte adoré des distros "classiques"? Pourquoi ne pas répondre à cette simple question sur les dates?
Ca commence à en faire des "pas si universel"… Pour info, toutes les distros passent à systemd, donc plus de soucis, y compris de dates, ton "format universel" pas si universel et ta façon de penser sont en train de se retourner contre toi… Quand le comprendras-tu? Sans doute aussi longtemps que tu as mis pour accepter UTF-8 dans tes logs "car je n'ai rien pour le lire".
[^] # Re: Un peu de lecture
Posté par xcomcmdr . Évalué à 3. Dernière modification le 08 mai 2015 à 14:20.
Je savais pas que le bloc-notes de Windows 9X savait lire l'Unicode (et avec des fins de ligne UNIX en plus !) ! Moi qui croyait que la prise en charge était très partielle, et que les développeurs devaient utiliser une couche de compatibilité par dessus l'API Win32 provenant de Windows XP pour chaque application voulant prendre en charge l'Unicode sur cette famille de système d'exploitations !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Un peu de lecture
Posté par briaeros007 . Évalué à 3.
n'importe quel logiciel qui sait lire des logs en ascii sait lire des logs en l'utf-8 ( (je précise bien le 8).
Les 127 premiers caractères sont ceux de l'ascii donc il te l'affiche sans problème la majorité des informations contenu dans un log (qui contienne assez peu de caractère spéciaux).
Tu aurais quelques "blob" lorsque tu auras des caractères spéciaux, mais dans un log ils sont suffisament peu important pour que ce soit pas grave.
Concernant le \r\n vs \n, j'avoue que je n'ai pas testé sous w9x , mais au dessus wordpad sait faire la différence et sait les gérer (mais pas notepad).
[^] # Re: Un peu de lecture
Posté par Michaël (site web personnel) . Évalué à 9.
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!
[^] # Re: Un peu de lecture
Posté par Michaël (site web personnel) . Évalué à 8.
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.
# que répondre devant tant de mauvaise fois
Posté par hervé Couvelard . Évalué à 6.
Mais je devais m'y attendre, je ne fais qu'exprimer le fait que systemd n'est pas la solution parfaite idéale dans un post qui ne parle pas de systemd mais de différence entre fichier texte et fichier binaire. Comment ai-je pu avoir la bêtise de proférer une telle chose dans le temple de la secte systemd.
Je passe sur zénitram, tel un chien de pavlov qui prend systématiquement le contre pied de ce que je dis, MÊME S'IL N'UTILISE PAS LINUX et qu'il parle juste pour occuper son temps.
Je passe sur les exemples crétins d'encodage que je n'utilise ni sur ma machine ni sur mon serveur.
Je passe sur les exemples stupides de la compression de la rotation des logs…
Et il ne reste rien.
Effectivement DANS CERTAINS CAS on ne peut pas lire un fichier texte car on n'a pas le bon encodage sur sa machine, effectivement DANS CERTAINS CAS le soucis se pose sur des logs archivés depuis longtemps et donc zipé.. enfin targezedés. Maintenant peut être qu'il est plus simple d'installer l'encodage que d'installer le logiciel qui peut décoder le fichier binaire ? mais je ne le sais pas.
MAIS il n'en reste pas moins le cas de mon serveur qui plante, dont j'ai les logs de la journée/semaine qui sont en mode texte dans MON encodage et que je peux lire avec mon éditeur de texte contre le fichier binaire d'un serveur et pour lequel je ne dispose pas du logiciel pour le lire.
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.
J'ai toujours pensé qu'il faut être un peu indépendant des outils que l'on utilise et, je dois être un peu con, mais je me sens moins dépendant lorsque les fichiers de configs et les logs sont en texte plutôt qu'en binaire. Parce que je ne suis pas capable de lire le binaire dans le texte, même avec hexedit.
Maintenant cela ne se fait pas ici de dire qu'on est dépendant d'un format que l'on ne maitrise pas (sauf si c'est windows). Bien entendu, il y aura des outils pour lire le binaire en question, bien entendu, il y aura des mécanisme pour ne pas broyer des logs important et ne pas continuer à écrire dans un fichier corrompu, bien entendu il y aura des manières de faire (de toute façon on n'aura pas la choix), mais il n'es reste pas moins vraie qu'il est plus simple de lire un fichier texte qu'un fichier binaire. Je n'y suis pour rien. Cela ne peut pas plaire, mais c'est un vérité.
[^] # Re: que répondre devant tant de mauvaise fois
Posté par Zenitram (site web personnel) . Évalué à -8.
tu crois sérieusement que je regarde le nom?
Tu ne veux pas passer quelques minutes à comprendre ce qu'est un format d'échange?
Euh… Déjà répondu, mais bien sûr tu préfères ignorer car bon ça ne te permettrai de continuer à cracher sur un logiciel que tu as arbitrairement décidé de haïr.
Surtout, ne pas démontrer tes affirmations.
Oui, avant on tuait les homos et on avait des esclaves, pourquoi changer alors que ça a duré des siècles, quelle honte de changer ça! Tu hurles? Mais c'est exactement la logique que tu veux qu'on accepte!
De pire en prie comme "arguments". N'essaye surtout pas de chercher à comprendre ce que les gens te disent, en te murant derrière un "MÊME S'IL N'UTILISE PAS LINUX" dont je ne vois pas ce qu'il fait ici.
PS : tu n'as toujours pas répondu sur ma question à propos de la date qui est en texte dans ton fichier texte, étonnant… Tu as aussi omis de hurler comme les autres ont fait quand on est passé de Latin-1 à UTF-8 "je peux pas les lire, UTF-8 ça pue" comme disaient du monde qui refusait UTF8 avec les mêmes argument que toi ici, mais c'était il y a 10 ans (un peu plus peut-être, je ne sais plus, souvenirs tellement lointain et ceux qui avaient balancé ça à l'époque éviter de rappeler qu'ils étaient contre UTF-8 de nos jours pour ne pas être ridicule).
PPS : Ca n'a absolument rien à voir avec systemd, ni avec Linux, le principe est général. Bref, belle démonstration de comment noyer le poisson quand on sait (inconsciemment?) que ce qu'on raconte ne tient pas. Perso j'ai attaqué tes idées dans ton commentaire, toi tu m'attaques personnellement, aveux de ne pouvoir attaquer les idées?
[^] # Re: que répondre devant tant de mauvaise fois
Posté par Albert_ . Évalué à 7.
tu crois sérieusement que je regarde le nom?
Non en effet il ne devrait pas prendre ca pour lui car en realite tu prends le contre-pied de tout le monde de facon systematique. Il n'y a donc rien de "personnel" la dedans.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: que répondre devant tant de mauvaise fois
Posté par Zenitram (site web personnel) . Évalué à -3.
Pour info je n'ai rien à faire de systemd, perso tant que ça marche je me fou de savoir ce qu'il y a derrière.
Zut alors…
Je n'arrive pas à comprendre comment les gens peuvent trouver l'idée de parler de "secte toto" dès qu'ils n'arrivent pas à expliquer leurs positions. Aveux que le discours n'est même pas logique pour soit-même?
Bizarre, moi j'aurai plutôt parlé de la secte fichier texte, c'est quand même les adorateurs des fichiers texte qui essayent d’empêcher les autres de vivre, et non l'inverse (systemd n'est imposé à personne, n'en déplaise aux pleureurs)
[^] # Re: que répondre devant tant de mauvaise fois
Posté par Marotte ⛧ . Évalué à 3. Dernière modification le 08 mai 2015 à 14:21.
L'exemple n'est pas stupide :
Tu sais lire un tarball dans un éditeur sans le décompresser au préalable ? Voilà, une fois ta log en texte brut compressée il te faut déjà un autre outil qu'un simple éditeur pour accéder à l'information…
Tu vas dépendre de systemd pour lire tes logs. C'est un logiciel libre, les sources sont disponibles, le format des journaux est donc ouvert. On a limite l'impression qu'on t'impose un format binaire fermé utilisable avec un seul soft propriétaire qui ne tournerait que sous Windows !
Ça dépend de ce que tu entends par « simple ». 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… Du point de vue de l'utilisateur j'entends. (et je note au passage que sous Windows grep n'est pas installé par défaut…)
[^] # Re: que répondre devant tant de mauvaise fois
Posté par Michaël (site web personnel) . Évalué à 7.
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
que de dire
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:
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.
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.
[^] # Re: que répondre devant tant de mauvaise fois
Posté par briaeros007 . Évalué à 5.
je rajouterais qu'avec l'idée du "all text", tu peux faire une approche itérative et rafiné les résultat au fur et à mesure.
Par exemple il arrive fréquemennt de
-> d'abord limiter la recherche à un range de date : un grep => dans un fichier (ou dans un pipe)
sur ces élements => je recherche tel pattern => hop un autre grep (ou sur le fichier spécifique si il est trop gros).
Le pattern je le vois car je recherche dans les logs et donc j'extrait à partir de ma lecture des logs le pattern qui me convient.
Une fois la deuxieme extraction effectué, j'analyse le format des lignes pour utiliser awk et sortir juste les champs intéressant et avoir une vue synthétique
je fait donc grep […] log > /tmp/toto
grep […] /tmp/toto >/tmp/titi
awk […] /tmp/titi
ou grep […] log |grep […] |awk […]
Ce n'est pas optimum, mais c'est quand même clair à lire et à expliquer derrière, et à réutiliser après.
On peut certaine extraire les logs journal en texte , mais il faudra aussi apprendre derrière sed , grep, awk etc… :)
[^] # Re: que répondre devant tant de mauvaise fois
Posté par Guillaume Rossignol . Évalué à 2.
Pour le deuxieme truc, il faut connaire sed, ainsi que l'encodage des dates dans le fichier de log… ecxemple tout con :
Et typiquement, l'intervalle de temps du 27 avril au 3 mai (semaine 18) avec sed, je ne suis pas certains que ca va bien marcher.
Ceci dit, je ne sais pas si logtool ferait beaucoup mieux, mais c'est juste pour souligner que le mode texte, c'est facile si on a prit le temps de tout configurer proprement pour que ce soit bien uniforme. Sinon, la formule du sed qui va bien est spécifique aux logs d'une appli.
[^] # Re: que répondre devant tant de mauvaise fois
Posté par robin . Évalué à 3.
Je suis tout à fait d'accord. D'ailleurs ça serait le même problème en binaire, avec une montée de version ayant des changements incompatible. :) La normalisation du format de donnée, c'est surtout pour que les ordis arrivent à les lire sans s'arracher les transistors ;)
Certes le mode texte est lisible par un humain, mais au final c'est la machine qui lit les logs, donc il faut faire en sorte que les logs soit lisibles par la machine, sous peine d'avoir un truc bancal.
bépo powered
[^] # Re: que répondre devant tant de mauvaise fois
Posté par Michaël (site web personnel) . Évalué à 9.
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
[^] # Re: que répondre devant tant de mauvaise fois
Posté par briaeros007 . Évalué à 3.
Je rajouterais, que si le besoin d'une BDD se fait sentir pour certains logs, rien n'empêche de le faire en cours de route. Que ce soit par insertion des fichiers de logs dans la BDD , ou configuration des outils de logs (rsyslog, …) pour tagger correctement les champs et les pousser ensuite.
Mais pour tout ceux qui ont eu à s'intéresser à ce travail : avoir un "schéma" utile et fonctionnel se fait type de log par type de log (même si certains type existe déjà ) et demande donc du temps à se mettre en place.
L'idée de "je balance tout dans une bdd pour faire après un LIKE '%toto%' " est , totalement contreproductive
# Pour toi?
Posté par Michaël (site web personnel) . Évalué à 5.
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.
[^] # Re: Pour toi?
Posté par xcomcmdr . Évalué à -2. Dernière modification le 08 mai 2015 à 19:51.
Pour moi.
Mais c'est une fausse dichotomie, vu que même ce qui est textuel est binaire.
Si j'apprends les outils binaires, j'aurais donc aussi appris les outils textuels. CQFD. ;-)
Je préfère quand même interroger journalctl plutôt que de sortir grep, des regex, sed, et awk, tout ça pour une histoire de putain de date à la con ou autre.
Y'a un moment où extraire les données, ben on se dit que ce serait à la machine de le faire, et il n'y aurait plus qu'à interroger un outil un poil plus "intelligent", quitte à ressortir grep & co. sur la sortie qu'il nous donne (c'est pas interdit, hein).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pour toi?
Posté par Moonz . Évalué à 7.
Par pitié, on pourrait arrêter de sortir cet argument complètement ridicule un jour ?
La distinction « format textuel/binaire » a un sens clairement défini, connu et compris par tous ceux qui ont une once de bonne foi (cf wikipedia). Et c’est pas la première fois que je te le fais remarquer. Du coup, la question que je me pose c’est : ça t’amuse d’étaler ta mauvaise foi ou tu cherches juste à m’énever ? Si c’est le second point, ça aurait pu réussir, si je prenais encore ce genre de provocations au sérieux.
Allez, un petit conseil de lecture pour passer le temps d’un manière plus productive http://lesswrong.com/lw/mm/the_fallacy_of_gray
[^] # Re: Pour toi?
Posté par xcomcmdr . Évalué à -3. Dernière modification le 09 mai 2015 à 00:12.
Par pitié, quand tu vas tu cesser de croire que le texte est un cas spécial ?
Du texte, du pas texte, c'est du binaire. Tout est binaire. Des zéros, et des un.
Pour ce format binaire, on s'est décidé sur
une normeune forêt de normes pour pouvoir le lire/écrire (EBDIC , ASCII, des pages de code à foison, UTF-8, format des fins de lignes …), ça ne s'est pas fait tout seul.Ensuite, les outils qui le traitent prennent en charge (à peu près) toutes les variantes courantes, mais ça ne s'est pas fait en un jour. Loin de là !
Donc au final, on a un format binaire, avec pléthores d'outils qui traitent du binaire.
Rien n'empêche d'utiliser un autre format binaire (comme celui de systemd-journald), et d'avoir des outils autour qui soient multiplateformes. Comme pour le cas du texte. Faut juste se décider sur le format. Ce n'est pas parce que ce n'est pas du texte que c'est forcément plus compliqué.
En fait, même du texte c'est compliqué. EBDIC ou ASCII ? ASCII ou UTF-8 ? UTF-8 ou UTF-16 ou … ? Avec ou sans BOM ? Codepage 1252 ou 1250 ou 437 ou une parmi des dizaines d'autres ? Avec des fins de ligne UNIX, Windows, ou Mac ?
Et t'as pas d'en-tête. Tout ça il faut le deviner en sondant le fichier !
Ça a l'air simple et pas si méchant aujourd'hui car c'est (à peu près) maîtrisé depuis
longtempsUnicode.Enfin ça, c'est pour la partie texte.
Pour les formats de logs, de dates et compagnie au sein d'un texte, on a encore beaucoup de "standards" qui se battent et qui n'arrangent rien.
Alors oui, peut-être qu'un autre format serait meilleur que tout ce merdier soit-disant pas binaire donc pas compliqué. Avec une autre approche. Comme celle de journald qui lui permet déjà de faire de l'auto-complétion sur ce qu'on recherche, de filtrer par service, boot, date, etc… C'est déjà pas si mal.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pour toi?
Posté par hervé Couvelard . Évalué à 4.
et bien lorsque l'on aura pléthore d'outils permettant de lire ces logs binaires merveilleux sous tous les os, dans tous les logiciels et des docs facilement accessible pour pouvoir les utiliser, je suis certains que tout le monde voudra l'utiliser.
Maintenant ceux qui doivent chercher dans les logs dont le pas de mesure est le giga octet et qui ont 5 secondes entre chaque recherche risquent d'être un peu chafouin, d'autant plus qu'il semble (mais je ne connais pas) compliqué de 'couper' le log en 2 pour se partager le travail.
Autre chose, il m'arrive de survoller les logs pour voir s'il n'y a pas de trucs bizarre… genre des requêtes avec des trucs louches (des suites de caractères qui semblent n'avoir aucun sens, avec tout plein de \ ou % dedans). Il me semble que pour requêter il faut donner ce que l'on cherche, si on ne sait pas ce que l'on cherche, comment on le requête ?
Je comprends bien qu'il est fastidieux de lire des logs dans le texte, mais cela permet de voir des trucs que l'on n'attends pas dans des logs, comment on arrive à résoudre ce truc avec le log binaire que l'on doit requêter à travers un logiciel qui sert d'interface ?
[^] # Re: Pour toi?
Posté par Thomas Douillard . Évalué à 7.
Parcourir les logs séquentiellement quoi ? c'est sur, c'est impossible avec autre chose que du texte. Genre journalctl en est incapable. Et puis l'application cliente reste libre de logger des messages textuels.
[^] # Re: Pour toi?
Posté par Moonz . Évalué à 10. Dernière modification le 09 mai 2015 à 08:04.
Les couleurs ça n’existe pas, c’est tout des photons d’abord.
Une baffe ou une caresse sur la joue, c’est du pareil au même, ce n’est qu’une force appliquée sur la peau.
Vanille ou chocolat idem, c’est que des protons, des neutrons et des électrons au final.
Avec ce genre de raisonnement on va pas aller bien loin.
Jamais, parce que le texte est un cas spécial, et que c’est pour ça qu’on a inventé la dichotomie format texte/format binaire, et que cette dichotomie existait bien avant les trolls systemd, et qu’elle n’a jamais été remise en cause avant les trolls systemd, ni même en dehors de ce contexte (allez, va défendre l’idée « vous saviez pas, mais HTML est en fait un format binaire » sur la mailing list du W3C, qu’on rigole)
De même, on a inventé la notion d’avion même si derrière c’est que des quarks. Parce qu’un avion c’est un cas spécial d’arrangement de quarks, et que c’est vachement plus pratique de manipuler la notion d’avion que d’expliquer comment tu vas de New-York à Paris en ne parlant que de quarks.
(analogie volée à http://lesswrong.com/lw/on/reductionism/, quitte à continuer dans les conseils de lecture plus utiles que cette argutie ridicule)
[^] # Re: Pour toi?
Posté par Zenitram (site web personnel) . Évalué à -8.
Ho souvenirs souvenirs… De cette saloperies de dichotomie texte/binaire dans FTP, qui pourrissait les transferts. Depuis, on force tout transfert FTP en mode binaire, même pour du texte. Ho tient ça me rappelle quelque chose que d'arrêter de penser que le texte est à part…
Que ça te plaise ou pas, le "texte" n'est qu'un format binaire comme un autre, et pire du pire : il n'est même pas défini précisément (et sa définition "commune" change suivant les époques et les régions du monde) et les "metadata" qu'on doit lui filer (à côté car incapable de stocker seul : codepage, format de date…) se perdent avec le temps. En pratique, on en chie autant voire plus avec du texte qu'avec du "binaire", de nos jours (surtout depuis que l’informatique ne se limite plus à l'occident).
Saloperie de faits.
Le monde évolue. Mais qu'est-ce que c'est difficile d'évoluer.
Rappel : personne n'oblige à utiliser systemd, vous pouvez garder votre format texte si vous le souhaitez (juste que d'autres ont décidé de ne plus travailler gratos pour vous, mais ça ça n'a rien à voir, pas de soucis la dessus)
[^] # Re: Pour toi?
Posté par Michaël (site web personnel) . Évalué à 7.
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!
[^] # Re: Pour toi?
Posté par Zenitram (site web personnel) . Évalué à -6.
exactement, merci de flinguer le mode "texte".
Car mon exemple FTP (et les autres : codepage, dates…) font partie du passé qu'il ne faut pas oublier et que les adorateurs du texte oublient quand il trouvent le "texte" si bien…
finalement, tu ne fais qu'appuyer mon propos, merci.
[^] # Re: Pour toi?
Posté par Antoine . Évalué à 4.
Ou comment mélanger tout et n'importe quoi.
Les codepages sous Windows sont simplement des jeux de caractères. Ils sont remplacés, non par du binaire, mais par unicode.
Quant aux dates, il y a des formats textuels standardisés et largement répandus.
[^] # Re: Pour toi?
Posté par Misc (site web personnel) . Évalué à 6.
la question est pas tant "texte" vs "binaire" que le degré de structuration que tu mets dans le format.
Un format XML va être du texte, va avoir une structure, et les métadonnées pour l’interpréter. Un format binaire qui est juste un dump mémoire ( comme le .doc l'était ) va pas avoir la structure.
Donc ça depend plus du format que juste "binaire" vs "texte". C'est un détail d'encodage en pratique.
Mais dans le cas des logs, les logs de syslog n'ont pas de structure et les logs de journald en ont.
Y a du pour et du contre, le fait de pas avoir de structure est plus rapide à développer et moins rigide vu que tu fais ce que tu veux. Exemple si je veux rajouter un truc à la fin des logs, j'ai pas à faire changer un schema ou quoi que ce soit.
Mais du coup, l’interopérabilité en souffre, dans le sens ou je peux pas m'appuyer sur le format. Et ça, c'est relou. Exemple, le format de mod_security est relou, vu qu'il log dans un premier fichier avec un format difficilement lisible par un humain, puis donne des détails dans un 2eme, un chouia plus difficilement scriptable car sur plusieurs lignes. Le fait d'inventer son format fait que je doit refaire la machinerie pour chercher la bas.
Donc la discussion devrait être "structure" vs "non structure".
Pas "texte" vs "pas texte". Car des formats texte de log avec une structure, y a gelf par exemple, qui peut être compressé et non compressé. Et même de manière plus amusante, il y a des convertisseurs ( https://github.com/systemd/journal2gelf ) depuis journald, parce que justement, il y a une structure.
[^] # Re: Pour toi?
Posté par gouttegd . Évalué à 5. Dernière modification le 10 mai 2015 à 21:08.
Non, l’un comme l’autre peuvent être structurés ou non-structurés.
Plus précisément :
Les informations autour du message de log (telles que la date, la machine, la priorité, etc.) sont toujours structurées, que ce soit avec syslog ou avec journald. La seule différence est que journald stocke beaucoup plus d’informations de ce genre qu’une implémentation typique de syslog (chez moi, syslog stocke uniquement la date/heure, le nom d’hôte, et le nom et PID du processus — mais toutes ces informations sont enregistrées d’une façon cohérente dans tous les fichiers de logs et sont parsables sans surprise).
Le message de log proprement dit (ce qu’envoie le programme au système de journalisation, via syslog(3) ou sd_journal_print(3)) peut être structuré ou non, mais la plupart du temps il ne l’est pas, c’est une chaîne de caractères que le programme formatte à sa guise. Je doute fort que journald change quoi que ce soit à ça, c’est entièrement du ressort du programme émetteur (et ça fait des années que la possibilité d’envoyer des messages structurés à syslog existe sans que personne ne s’en serve, donc je ne vois pas pourquoi tout le monde déciderait subitement de le faire juste parce que journald le permet aussi).
Les programmes qui se chargent eux-mêmes de leurs propres logs (souvent avec leur propre format) au lieu de passer par le démon de journalisation du système poseront toujours problème, peu importe que le démon de journalisation soit syslogd ou journald…
[^] # Re: Pour toi?
Posté par Misc (site web personnel) . Évalué à 8.
Sans surprise, autre que "j'ai changé la langue du systeme et le timestamp a changé". Et sans surprise autre que "j'ai des entrées multilignes dans les logs et ça peut foutre la zone dans mes scripts" ? Ou sans surprise autre que "c'est relou de faire des calculs sur les dates comme trouver tout depuis 1h30" quand tu regardes pour des infos à partir de 1h15 du mat ?
Je sais pas si j'ai vraiment la poisse ou si j'ai juste gardé mon ame d'enfant, mais ça, j'appelle ça des surprises. Des trucs auquel tu penses pas sur le coup, mais dés qu'il faut s'y mettre "surprise".
Comme tu le dit, l'interface de syslog, c'est d'ouvrir /dev/log, d'écrire dedans., c'est "tu files une ligne + la priorité" ( man 3 syslog ).
L'interface de journald, c'est soit tu utilises la même chose que syslog ( sd_journal_print ), soit tu utilises sd_journal_send ou tu passes des couples clés/valeurs.
Donc à partir de la, si mod_security veut du clé valeur, soit ils vont faire comme maintenant, cad écrire du structuré que personne ne va lire facilement ( en l'occurence, ça passe via les logs standards d'apache, c'est pas lui qui va écrire ), et qui va arriver avec le reste dans un fichier texte avec un bon mix.
Soit utiliser journald, ou la même chose va arriver, mais ou le filtrage du mix est builtin, pour peu que mod_security fasse ce qu'il faut.
Tu dis que personne ne se sert de l'envoi de messages structurés alors qu'on pouvait depuis longtemps. Mais c'est exactement ce que mod_security fait, et c'est la plaie, parce que justement, il fait ce que les autres ne font pas, cad envoyer du structuré et qu'il faut quelque chose pour s'en occuper.
Et c'est parce que c'est la plaie de faire ça avec la machinerie de syslog que personne le fait. Et ça n'a pas pris pour des questions de poule et d'oeuf.
Personne ou presque ne s'en sert parce qu'aucun format/lib/systéme n'a pris. Et donc aucune interface de recherche n'a été adopté par les gens en standard au delà de grep. Comme tout les trucs qui proposent ça sont lourd ( splunk/elk/graylog ), seul les gros groupes déploient ça, donc pas de standard, donc rien ne prends. Et Journald, qui fait ça de façon plus simple pour l'admin, a changé ce cycle de 2 façons.
Primo, en rajoutant l'information de structure sans demander au programme. Tu as l'unité, le pid, etc, etc. Et de façon uniforme sur tout les daemons juste en se mettant au bon endroit. Quelqu'un qui aurait voulu mettre l'info dispo aurait juste eu à coder le support dans rsyslog et à mettre une configuration par defaut. Mais à la place, l'approche des gens, c'était "on va mettre ça sur chaque daemon", ce qui visiblement n'a pas pris.
Les utilisateurs ont un souci, ils vont voir l'upstream. l'upstream va juste penser à influencer son soft, pas l'ecosystéme autour, et on arrive à la situation plus haut.
Secondo, une fois que l'information était la, il suffisait juste de rajouter une interface pour l'utiliser ( journalctl, en l'occurrence ). Et une fois que tu commences à utiliser l'info, tu continues.
Bien sur, ça aurait pu être fait avant et sans journald, qui n'a rien de magique à ce niveau ( aprés tout, Windows NT le fait depuis un bout de temps ). Mais comme maintenant, c'est en place, ça commence à être adopté.
Exemple, apache propose ça :
https://httpd.apache.org/docs/trunk/mod/mod_journald.html
Pareil pour cupsd ( https://fedoraproject.org/wiki/Changes/CupsJournalLogging )
Y a pas besoin que les gens s'y mettent, suffit juste d'avoir une configuration par défaut dans une distribution, et que ça soit intégré.
[^] # Re: Pour toi?
Posté par robin . Évalué à 5.
D'ailleurs un autre avantage du texte c'est de prendre en compte de manière transparente et native des changements considéré comme majeur en binaire.
Par exemple, si pour la date, on stocke un timestamp. Actuellement, il est « 1431114318 ». En binaire, on utilise 32bits pour stocker cette information. Le jour où on va passer en 64 bits, on va tout casser. En texte, on va stocke une chaîne : "1431114318", suivit d'un délimiteur (espace, deux points, …). Le jour ou on aura besoin d'un timestamp plus long, et b'en on va écrire un timestamp plus long. C'est tout.
Le gros avantage du texte, c'est la stabilité très longue durée (Unix à plus de 40 ans). Un format binaire est incapable de vivre aussi longtemps. Par exemple du C de 1990 est toujours compilable à l'heure actuelle, même s'il peut être difficile de l'exécuter (problème de librairie). Un binaire, c'est quasiment impossible d'en tirer encore quoi que ce soit.
bépo powered
[^] # Re: Pour toi?
Posté par robin . Évalué à 9.
Tant que j'y suis dans les avantages longue durée du texte, il y a aussi celui-ci.
Supposons que l'on a beaucoup de log, et que l'on veut les conserver très longtemps. Il faut donc les compresser, la question ne se pose pas.
Choix 1 : log binaire, avec une structure de donnée efficace. On a un bon taux de compression.
Choix 2 : du texte. C'est verbeux, donc ça prend de la place. Mais, par ce qu'il y a un « mais », il y a une astuce. On manipule toujours les logs décompressé, comme ça on a besoin d'un seul outil (ou suite d'outils) pour les manipuler. En revanche pour le stockage, on les compresse. L'avantage, c'est que l'on peut avoir plusieurs types de compression. Je m'explique. Pour les logs récents ou récemment consultés, on utilise une compression très rapide (tel que lz4). On a donc un léger gain de place, et une faible perte de vitesse. Pour les logs anciens, et non récemment consultés, on peut utiliser un autre algo, avec des paramètres qui favorise le taux de compression. On a donc un très bon taux de compression en moyenne (la majorité des logs sont fortement voir très fortement compressé), tout en ayant en moyenne une très bonne vitesse de lecture (les logs récents sont en texte brut ou en lz4). De plus, les outils de compressions possèdent plusieurs implémentations documentées, et on possède des outils génériques en cas de corruption des archives.
Le double effet kiss cool, c'est que le jour ou on invente un nouvel algo de compression, avec les logs binaires, il faut tout mettre à jour : le format, et les outils pour les utiliser, ainsi qu'un convertisseur. Avec les logs textes, pas besoin de réinventer la roue. On utilise toujours les mêmes outils (ils ne savent lire que du texte décompressé de toute façon), et pour la migration, il suffit d'utiliser le décompresseur (qui existait déjà, vu que c'est celui que l'on utilisait avec l'ancien format de compression), puis de recompresser avec le nouvel algo (dans son implémentation standard). On n'a donc presque rien rajouté de spécifique dans notre code (seul les appels de fonctions compresse() et decompresse()), malgré une mise à jour significative de l'outil de stockage. Donc sur le très long terme (plus de 10 ans), ça peux être un avantage.
bépo powered
[^] # Re: Pour toi?
Posté par robin . Évalué à 8.
Et qu'on soit clair. Quand on parle de log en texte, on parle uniquement de la partie stockage (le modèle). Il est bien évidemment pertinent de fabriquer un outil dédié (pour la vue) spécifique aux informations que l'on stocke dans nos logs (avec pourquoi pas un langage de requête).
Je n'ai pas bien compris dans les différentes discussions pourquoi est ce que les gens qui parlent du stockage binaire opposent forcément stockage texte à interface dédié. Ça me semble totalement orthogonal.
bépo powered
[^] # Re: Pour toi?
Posté par Guillaume Rossignol . Évalué à 2.
Effectivement, ça l'est, mais un des arguments qui revient souvent pour le format texte des logs c'est «Avec grep (cat/awk/… un outil de traitement de texte généraliste)» je peux faire des recherches rapides. Du coup, ça entraine un biais, c'est qu'on finit par oublier qu'un log texte ca peut être structuré (mais du coup, l'argument «je l'analyse aussi facilement de partout avec grep» tombe un peu à l'eau)
[^] # Re: Pour toi?
Posté par ckyl . Évalué à 9.
En même temps partir du moment où tu as un convertisseur format de stockage vers représentation textuelle, ie. tu remplaces le cat initial part une commande spécifique, et tu peux très bien avoir le même workflow que ton sed/grep sur un fichier textuel.
Les seules différences sont que:
a chaque essai tu vas repayer le cout de la conversion ce qui est potentiellement beaucoup plus lent qu'aller chercher des octets dans le cache VFS (mais on optimise facilement en cachant au besoin).
il faut avoir l'outil de conversion. Dans la vraie vie ça ne pose pas problème. Les points de conversion sont maîtrisés. Si tu cherches à communiquer avec des gens qui veulent du texte tu sors du texte (que ce soit non structure, du json, du tsv etc.). Avec tu texte tu envois à quelqu'un le résultat de cat log | grep, la tu envois les résultats de xxx-cat | grep…
Et pour toutes les âneries qui ont été écrites sur les formats binaires tel que la plus grande robustesse du texte à la corruption, ou sa plus grandes évolutivite je pense qu'il faut revenir à la base d'une conception correcte… ce n'est par ce que des formats ont été mal conçus que c'est une fatalité. On peut avoir les mêmes propriétés que du texte si on le souhaite. Ça se choisi juste en fonction des besoins non fonctionnels exprimés (et au passage le texte non structuré c'est génial pour oublier de spécifier ce qu'on produit alors oui tu m'étonnes que c'est souple…)
[^] # Re: Pour toi?
Posté par xcomcmdr . Évalué à 9.
Alléluia !! Enfin quelqu'un qui a la tête sur les épaules ! Je commençais à désespérer face à tant de bêtise.
D'ailleurs le format qu'utilise systemd-journald est justement robuste face à la corruption (autant que du texte), entre autres propriétés intéréssantes :
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pour toi?
Posté par robin . Évalué à 3.
J'ai aussi du mal à voir pourquoi les gens ne se fabriquent pas des interfaces dédiées qui forgent facilement les requêtes grep/sed/awk de barbus pour eux (typiquement les dates).Quitte à finir avec grep/sed/awk à la main, une fois que le résultat est pré-maché.
bépo powered
[^] # Re: Pour toi?
Posté par Misc (site web personnel) . Évalué à 1.
Bah, si tu veux la réponse, tu peux te poser la question à toi même.
Sinon, ça existe déjà, ça s'appelle SQL ( le standard SQL qui date d'avant awk, je tiens à rappeller ). Tu as tes données, tu fait des selects, des LIMIT, des clauses WHERE, etc comme tu ferait avec grep/awk/sed. Et des requêtes sur les requetes, pour les bases de données assez avancés. Et des stockages en tables temporaires aussi, si tu as envie.
Sinon, plus prosaïquement, le reste du monde n'a pas attendu que tu te poses des questions, et le monde scientifique a depuis longtemps des notebooks, comme zeppelin, ipython/jupyter. Sans vouloir trop m'avancer, je pense que l'inspiration vient de maple ou mathematic, et que l'idée, c'est d'avoir un cli amélioré via le browser.
Et pour tout ce qui est big data, ç'est le truc que propose tout les éditeurs de ce que je vois du marché.
Par exemple, Zeppelin te permet d'interroger ton cluster spark pour faire des requêtes sur les flux en streaming, requêtes qui sont peu ou prou semblables aux concepts de grep/awk/etc. Et q
Par exemple pour spark, voir word count, ou on chaine les traitements :
https://spark.apache.org/examples.html
Pareil pour jupyter/ipython et les autres.
Maintenant, libre à toi de rajouter des choses, ipython/jupyter a la possibilité aussi de traiter du bash :
http://jeroenjanssens.com/2015/02/19/ibash-notebook.html
[^] # Re: Pour toi?
Posté par Misc (site web personnel) . Évalué à 4.
J'ai du mal à voir en quoi une mise à jour peut être à la fois "significative" et en même temps "ne rien changer pour personne". Tu as juste changer le format de compression, ce qui est comme tu le dit un détail.
Sinon, il manque aussi le fait de devoir stocker le format de compression quelque part, sinon, ton format est indéfini ( déjà que les logs sont pas dans des formats définis de base ).
Et tu compares des choses en faisant preuve d'un manque de vision assez curieux. Tu part du principe que tu peux mettre à jour la chaine de traitement pour le cas ou ça t'arrange ( format texte ) mais pas pour le cas ou ça t'arrange pas, alors que ça peut se faire avec la même difficulté dans les 2 cas. Dans un cas, tu va avoir une routine de décompression, dans l'autre aussi. Dans un cas, tu va devoir spécifier le type de compression, dans l'autre aussi. Sauf que dans le cas ou ça t'arrange, c'est facile et rapide, et dans le cas ou ça t'arrange pas, c'est impossible. Mais sans justification aucune, ce qui est normale vu qu'il y a aucune raison logique à ça.
Le plus gros souci de tout ton argumentaire, c'est que tu confonds "dump de texte non structuré" avec "format texte".
Et si ton exemple d'évolution du texte non structuré, c'est "changer le format de compression", tu te fourres le doigt dans l'oeil sur la réalité des choses. Ce qui arrive bien plus souvent, c'est que le format de sortie change. Parce que tout d'un coup, tu as mis un nouveau module qui rajoute des choses ( exemple, tu passes tes serveurs webs derrière des proxys, donc tu veux logguer le X-forwarded-for en plus du proxy qui a fait le relais ). Ou tout d'un coup, tu as mis de l'ipv6. Et la, c'est le drame. Parce que tout d'un coup, ton script qui compte les champs avait pas prévu que tu tu aurais un champ de plus. Parce que tout d'un coup, ton champ texte qui est toujours la est tout d'un coup plus grand, avec un format différent. Parce que tout d'un coup, ton script qui fait que de l'ascii doit gérer l'unicode parce que quelqu'un utilise de l'IDN.
Prendre les données sans le reste de la chaine en croyant que "ça suffit", c'est se planter.
[^] # Re: Pour toi?
Posté par robin . Évalué à 1.
Merci pour ta critique intéressante. C'est tout à fait ce genre de commentaire que j'attendais en exposant mes réflexions.
bépo powered
[^] # Re: Pour toi?
Posté par Misc (site web personnel) . Évalué à 8.
Tu fait des fausses dichotomies. C'est surtout dépendant de comment tu spécifie ton format.
Si tu dit "le timestamp est une chaine de maximum 10 caracteres", alors le jour ou tu passes à 11, tu casses tout et c'est du texte.
Si tu as un format binaire avec un entête qui donne la longueur ou ce genre de choses ( ce qui est fait par exemple en ipv6 ), alors tu peux gérer la transition.
Et les délimiteurs sont pas sans poser des soucis, tel que "devoir les échapper". je fait quoi si j'ai besoin d'avoir un espace ou ':' dans ma chaine ?
Tu aurais du commencer par ça, parce que la, j'aurais compris que tu as visiblement aucun recul et que tu mélanges tout. J'aurais pas pris la peine de répondre.
Primo, tu peux toujours lire les fichiers zip et afficher les bmp des années 80. Donc tu repasseras pour le fait d'être incapable de durer aussi longtemps. La principale raison de la longévité d'une information, c'est d'avoir un standard qui décrit quoi faire des données, pas d'être au format texte. Par exemple, va prendre des fichiers xml sans avoir la dtd ou l'info de ce que doit faire, tu va t'éclater à tirer des informations de ton format "perenne" en mode texte.
Secondo, si ton programme C des années 90 est compilable, y a des chances qu'il s’exécute aussi. Pas forcement qu'il s’exécute correctement si il fait de la merde toléré à l'époque qu'on bloque maintenant. Ça a beau être du texte, encore une fois, ce qui est important, c'est l'usage qui est fait de l'information, pas le format.
Donc l'argumentaire est un chouia myopique.
[^] # Re: Pour toi?
Posté par groumly . Évalué à 6.
Sans compter que ya des prgrammes c des annees 90 qui tournent encore de nos jours (une large partie des binaires dos/windows), et je suis loin d'etre convaincu qu'ils soient simple a compiler.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
# OSEF
Posté par totof2000 . Évalué à 2.
Que toi ou d'autres préfèrent les journaux binaires, tant mieux pour vous, personnellemnt je m'en fiche, tant que je peux continuer à utiliser les journaux en mode texte.
[^] # Re: OSEF
Posté par Zenitram (site web personnel) . Évalué à -5.
Comme personne ne te force à ne pas utiliser les journaux en mode texte, pas de soucis, en effet.
Chacun utilise ce qu'il veut, chacun fait le boulot pour que ce qu'il veut marche.
[^] # Re: OSEF
Posté par Antoine . Évalué à 10.
En tout cas, si les journaux Linuxfr n'étaient pas au format texte, il y aurait probablement moins de commentaires binaires en-dessous.
# Merci
Posté par hervé Couvelard . Évalué à 9.
Je profite du calme pour dire merci aux personnes qui postent des réponses intelligentes, qui donnent des pistes de réflexion (base de donnée ou pas, pourquoi, passage à l'échelle, réutilisation des connaissances et des données….) qui donnent des points de vue qui viennent d'autres façons de travailler et de procéder, qui passent de leur temps pour faire avancer la connaissance sur un point particulier.
J'adore apprendre que j'ai tord sur certains points car cela me fait avancer et me fait découvrir des choses que je n'imaginais pas.
Par contre, il est évident que je ne parle pas de ceusse qui viennent pinailler sur des points de détails et sortent des exemples d'une incongruité qui n'est pas le reflet d'une construction intelligente de la pensée.
[^] # Re: Merci
Posté par totof2000 . Évalué à 3.
J'en profite donc pour te dire que tu as torT ;)
[^] # Re: Merci
Posté par hervé Couvelard . Évalué à 2.
merci, je sais bien que le torTue c'est torDu hein ?
# Définition
Posté par robin . Évalué à 0. Dernière modification le 09 mai 2015 à 12:12.
Tout le monde s'arrache les cheveux dans ce thread sur la distinction binaire/texte. Je propose une définition, ditessmoi ce que vous en pensez.
Le fait que ce soit binaire ou texte est une question d'encodage, la façon dont on va enregistrer les données. La structure des données n'a rien à voir (on peut avoir une structure très flat en texte comme en binaire, des arbres en texte comme en binaire, …). De même la normalisation est orthogonale (on peut normaliser du texte et du binaire, ou faire n'importe quoi).
Un format texte est un format d'encodage générique, partagé par de nombreux types de donnés différents, dans de nombreux contextes, et de multiples applications, et ne sont pas liés à des contraintes matérielles. Il existe de nombreux types de format texte, mais ils partagent tous la caractéristique d'être agnostiques de la structure de données qu'ils encodent.
Un format binaire est un format d'encodage spécialisé dédié à un type de donnée, dédié à un contexte, ou un type d'application. Les formats binaires peuvent être liés à des contraintes matérielle (tels que l'endianess). Il existe de nombreux types de format binaire, chacun dédiés à un format de donnés.
edit: Je ne tiens à faire l'apologie ni de l'un ni de l'autre, ces deux formats d'encodage sont tous les deux valables dans un contexte donné.
bépo powered
[^] # Re: Définition
Posté par Zenitram (site web personnel) . Évalué à -5. Dernière modification le 09 mai 2015 à 12:31.
un format binaire est aussi agnostique qu'un format texte : les deux ne sont qu'une suite d'octets dont on spécifie (plus ou moins bien, j'attends toujours la spécification d'un format "texte" accepté par tous) la signification.
Tu ne tiens pas à faire l'apologie, mais rien que le fait de faire une différence comme tu le fais t'embarque dans la discussion, car le gros problème du "format texte" est que tu n'en dis pas assez.
Reformulons : Il existe de nombreux types de format texte, mais ils partagent tous la caractéristique d'être agnostiques de la structure de données qu'ils encodent et de l'encoder comme l'encodeur veut, du coup on ne sait finalement rien à part pour un humain qui essayera de déchiffrer (je dis bien déchiffrer, car la règle est perdue, exemple 11/12/13 signifiera des choses différentes et seul l'humain, en fouillant, peut en comprendre la signification réelle, et lire en ASCII un fichier texte encodé en Big-5 est assez folklorique, ne parlons pas que le texte est très souvent compressé donc… Binaire).
Un format binaire est plus ou moins spécialisé (je pense notamment au BXML, binaire et bien mieux spécifié qu'un format "texte" tout en étant aussi générique que du texte) et est lisible par un lecteur spécialisé dans ce format comme l'est un lecteur "texte" pour un format "texte" (qui sera incapable de lire un tar.gz, mais chut, les adorateurs du texte ne compressent pas, ça serait avouer que le texte a un défaut, et il faudrait utiliser un outil externe).
Comme quoi, la définition est déjà un problème, car ceux qui passent au "binaire" voient justement que le texte n'est pas si agnostique que ce que les adorateurs du tout texte veulent faire croire… D'ailleurs, on peut juste dire que le format journald n'est qu'un format texte compressé, il existe un décompresseur de tar.gz et on peut utiliser un décompresseur de journald. Sérieusement, en réalité, quelle différence entre un log tar.gz et un log journald? aucun, les deux ont besoin de "traducteurs".
[^] # Re: Définition
Posté par hervé Couvelard . Évalué à 5. Dernière modification le 09 mai 2015 à 12:48.
cool, bientôt les document .docx stockés en bmp.
[^] # Re: Définition
Posté par Thomas Douillard . Évalué à 4.
et bientot des bmp stockés en unicode ?
[^] # Re: Définition
Posté par robin . Évalué à 1.
Par exemple celui-ci. Site officiel.
Enjoy :)
bépo powered
[^] # Re: Définition
Posté par Thomas Douillard . Évalué à 2.
Tu dois confondre avec le truc qui s'inclue dans un source C. Mais à ce compte là faut rajouter la grammaire de C … autant coder de lunicode dans des pixels BMP et rajouter un programme qui décode le tout.
[^] # Re: Définition
Posté par robin . Évalué à 2.
Je suis vraiment trop con, j'ai confondu avec le SNG, qui est lui par contre une représentation texte du png. C'est dommage, j'ai loupé mon effet :(
bépo powered
[^] # Re: Définition
Posté par hervé Couvelard . Évalué à 5.
cool, c'est une bonne nouvelle, quelle est le décompresseur journald sur windows ?
[^] # Re: Définition
Posté par Zenitram (site web personnel) . Évalué à -1. Dernière modification le 09 mai 2015 à 13:06.
Ta phrase veut juste dire qu'il est impossible de passer de tar.gz à tar.bz2 (à un moment donné, tar.bz2 n'est pas lisible par le Linux du voisin, donc il ne faut pas faire, donc on ne fera jamais. Pas de chance! des gens y sont quand même passé, pire ils passent à xz maintenant, qui a le même problème de ne pas être lisible partout)
Ce genre de phrase arrête toute discussion car montre que la personne n'acceptera jamais la moindre évolution, par principe (ou alors c'est juste pour ce cas la et ça montre la mauvaise foi, pas mieux, la personne montre qu'elle cherche n'importe quelle excuse bidon pour détester ce qu'elle a arbitrairement décidée de détester, il faut bien se rassurer…).
C'est triste.
PS : par défaut, Windows ne sait pas lire les tar.gz. donc ne jamais compresser ses logs (en plus, ce ne serait plus du texte, il ne faut pas déjà pour un autre principe, mais chut), on ne sait jamais si on ne peut pas avoir un décompresseur qui va bien un jour… Ou alors, se dire que c'est des conneries. snif. Ou vaut mieux en rire tellement c'est de l'humour.
[^] # Re: Définition
Posté par Antoine . Évalué à 4.
Et donc, quel est le décompresseur journald sur windows ?
[^] # Re: Définition
Posté par Misc (site web personnel) . Évalué à 10.
D'après stackoverflow, il suffit juste d'utiliser le module struct de python. Parait que c'est un langage sympa, faudrait regarder.
Mais je pense que la question est purement réthorique, parce que malgré la doc présente sur le web ( http://www.freedesktop.org/wiki/Software/systemd/journal-files/ ) depuis des années et le fait qu'il existe 2/3 bouts de code pour le faire ( https://github.com/Lagg/c3-code/blob/master/journal.c et https://github.com/Laird-Dave/journaldparser/blob/master/extractor.py ), le fait est que personne n'a pris la peine ( ie, l'aprés midi de travail ) de faire quoi que ce soit de propre pour windows ou pour mac. Ça montre surtout que l'intersection des gens motivés et/ou capables de coder pour ces platformes et des gens ayant le besoin est proche de pas grand chose. Et c'est pas faute pourtant d'avoir des tas de gens qui disent qu'il faut le faire, vu le nombre de commentaires disant qu'il y a un souci et tout va exploser.
Si franchement, un mec arrive à coder ça dans le cadre d'un tutorial youtube en écrivant les 250 lignes requises de code, c'est que ça doit pas être si terrible.
Donc si c'est pas la difficulté qui bloque, soit c'est parce que les gens sous Windows sont incapables, soit ils ont pas le besoin. Je ne pense pas que les Windowsiens sont incapables, et vu les pavés que hervé poste sur ce thread, je pense pas qu'on puisse garder l’hypothèse qu'il n'a pas le temps ( ça m'a pris 5 minutes de recherche sur le web pour trouver le code ).
Donc j'en conclus que le besoin est suffisament faible pour que quelqu'un se motive à faire un truc.
Et c'est pas vraiment compliqué de voir pourquoi. Si c'est sur un serveur, la majorité des OS utilisé ayant systemd a également les logs en texte à coté, cf config RHEL/Centos, et Debian, en partant du principe qu'il y a pas autre chose mise en place, genre splunk, ELK, etc.
Si c'est pas sur un serveur, c'est sur un poste client et/ou embarqué, ou une variante. Et si c'est sur un poste client, y a des chances de préférer un Linux par la.
Encore une fois, prendre le code python que j'ai pointé, en faire un module qu'on met sur pypi, faire des builds kivonbien, c'est moins d'une journée de travail pour quelqu'un d'assez compétent. J'ai écrit un gem ruby en partant de 0 en moins de 4h depuis un café en république tchèque y a grosso modo 1 an, donc j'imagine que pypi doit pas être fondamentalement plus complexe.
Donc si le but était d'être constructif plutôt que de déposer une énième logorrhée sur Linuxfr, quelqu'un s'y attellerait. Personne ne s'y attelle, donc je conclue que le but est juste de râler.
Moi, je pourrais en effet faire ce module, mais je vois pas pourquoi je devrais consacrer du temps gratuit à une plateforme que j'utilise pas, que j'ai pas envie d'utiliser. Mais si quelqu'un me file des thunes, je peux changer d'avis. J'ai l'intuition que personne ne va rien donner, donc ça doit pas être si critique que ça.
[^] # Re: Définition
Posté par hervé Couvelard . Évalué à 3.
Non, je crois que tu ne comprends pas (ou ne veux pas comprendre), j'espère que c'est le deuxième cas car sinon je suis triste pour ton incapacité intellectuelle.
Je ne suis pas contre l'évolution, la preuve mon système est en utf8 et d'ailleurs, il y a des moment ou c'est chiant car si je suis en ssh sur un serveur en isochose j'ai des caractères zarb. Alors je suppose que je peux régler le soucis avec une ligne de commande, mais le désagrément n'est pas assez fort pour que je passe du temps à comprendre.
Lorsque je fais une install d'un système en anglais le clavier est nativement en qwerty, c'est méga chiant lorsque tu as un azerty. Je pourrais brancher un clmvier usb en qwerty, mais je fais avec parce que je passe vite à un moment ou je peux dire azerty.
Je n'utilise plus le win3.1 (qui fonctionne encore) sur le vieux portable, même si je pourrais encore jouer à démineur et taper du
textebinaire que je pourrais lire sans me prendre la gueule sur les dernier truc qui vient de sortir. Je ne veux pas que les choses ne changent pas, j'aime bien que les AVANTAGES que te procure cette évolution soit SUPÉRIEURS aux ennuis que cela te crée (changement de process, d'outils, de méthodes de travail, apprentissage de nouveaux outils …). Par exemple, je trouve ridicule les évolutions qui nécessitent de doubler ta ram pour faire exactement la même chose. Mais je conçois totalement que certains le veuillent et aient besoin de changer de machine tous les 6 mois ou de gsm tous les ans. Mon gsm est un nokia E71 que j'ai eu pour 1 euros il y a 4, 5 ou 6 ans ? Il correspond parfaitement à ce que j'ai besoin, même si PARFOIS j'aimerais avoir un diamons ou un démineur pour passer 15 minutes entre 2 trucs. MAIS ce que cela implique en terme de plein de choses ne justifie pas à mes yeux le supplément de confort de pouvoir jouer 3 fois dans le mois pendant 15 minutes.Maintenant je vais réponde à ta question stupide sur la date 11/12/13 parce que tu sembles faire un blocage dessus. EFFECTIVEMENT si on ne sait rien, on ne peut pas savoir quelle date c'est, même si c'est une date. ce que l'on sait c'est que 13 ne peut pas être le mois. Maintenant si j'ai un fichier avec des trucs comme cela :
11/12/13 uZEIOUF ERICDIK IÇOISDc pozjef
12/12/13 liqdoi oiaerg opzorth sreojzrt
13/12/13 oklkjo aeroijaer aergaerg aeaeg
je peux peut être supposer que que le premier est le jour, le deuxième le mois et la fin l'année.
MAIS si j'ai plus loin
11/14/13 c'est l'inverse (le mois en premier et le jour en deuxième)
et si j'ai encore plus loin un truc comme
76/32/45 il est fort peu probalement que ce soit une date.
Maintenant que j'ai répondu à ta question, j'aimerais que tu me fasse la même analyse avec cela
stream
�{U�)�,�$!<����y�v��m
9��6���&����oɖ,��3�CX�z�eY*�z��lr����׆��ОX�3l�����S���N�o�����x�y���h>ܠ����m$0�HpjGB�#��MG>�vW;y����:�8<Mt$gu���"/�������j��82��L���~��p��WSm�S߰O��+s��T�h`O��j����ѹ��N�A?�I{9K&�N�
I�o�w�v>yXHO�Y��(t,L�����@ ��a*o�:�c7B�1'�a{���@��+W���nm�<�Kg�Hs�����y��r�� ��v8�b9r����
����,�1O��:
H�����Z�a���h�)�!���2��
5"e�v�]�Үw���r7�@��x���&���$PG?��D4/3�qki{��ZNH'���|v*ӹk��L�����������Q�!�DI��?��6��دXn���!�3.%gu|���
��v;�im��W��b�fa�X喆�b�ơ2���jx����l�
�.�p�N�!��T(Rq�V1�uXl���Y�AO5�G|Q���c:�q���[5�a=��\$zRY�.P[[p��[�Y,�p�#�2[��Sr�L�jn �t3FG��
��D�x��<[F�
������f��
Comme cela je pourrais bénéficier de ton grand savoir
[^] # Re: Définition
Posté par Zenitram (site web personnel) . Évalué à -5. Dernière modification le 09 mai 2015 à 15:48.
Un truc idiot : j'explique pourquoi ça migre aujourd'hui vers du "binaire" (façon de parler), comme pourquoi c'est en train de passer de tar.gz au tar.xz malgré le même problème que tu décris. Toi, tu réagis en résistance au changement et attaque l'autre personnellement; on m'a toujours dit que les gens qui attaquent personnellement ne croient pas eux mêmes intérieurement en ce qu'ils disent, mais c'est des "on dit", certes.
et la seule attaque que tu trouves est de sous-entendre "incapacité intellectuelle" juste parce que j'ai le malheur d'être en désaccord avec toi (en fait, le monde des distros est en désaccord avec toi et passe malgré tout au format journald malgré les "ho ça fait peur" de certains, mais c'est un autre sujet) sans chercher à comprendre ce que dit l'interlocuteur (il a forcément tort de toutes façons).
Bref, je n'ai rien à comprendre, je sais (que je sais) pourquoi des gens migrent, pendant que d'autres refusent d'essayer de comprendre pourquoi d'autres migrent et cherchent n'importe quelle excuse pour refuser l'évolution (rappel : que personne ne force, les gens prennent l'évolution car ça leur sert, aucun flingue sur la tempe)
"Si", voila, tout est dit. impossible d'automatiser, d'être sûr. Merci pour la démonstration.
Juste pour info : mon métier est en grande partie d'automatiser la détection de problèmes provenant de personnes ayant codé avec des "si" d'une spécification peu claire (et bizarrement, les gens avec des "évidences" à la hérvé, ben ils ne comprennent pas la même chose à travers le monde). Des "si", je sais par mon métier que ça ne marche jamais à 100%.
Exactement de la même manière que toi : avec un outil qui sait afficher en langage humain.
Rappel : ce que ton outil affiche 11/12/13 (que tu dis "texte" mais qui en est pas, c'est une représentation), c'est 31 31 2F 31 32 2F 31 33 stocké. Ben moi, j'utilise un outil qui affiche correctement 9��6���. Un outil partout, aucune différence.
Partout la même chose : l'utilisation d'un outils. En bonus l'humain qui doit comprendre quand c'est en "texte". J'avoue ne pas comprendre ce qui coince dans la compréhension, à part la mauvaise foi pour ne pas voir la réalité en face.
Rappel : journald permet d'afficher du texte compatible avec ton outil. Ben oui, c'est juste une représentation d'un format binaire que tu donnes.
Je vais m'arrêter la, de toutes façons ça fera comme pour toute évolution (quelques années plus tard, les gens qui hurlaient à l'horreur éviteront de rappeler qu'ils étaient contre ce qui est évident à ce moment-la, ils feront profil bas tellement ils ne souhaite pas qu'on se foute de leur gueule).
Encore une fois : rien de nouveau ici, ce n'est que l'évolution et les problèmes identiques à chaque fois qu'il y a une évolution, ici n'est pas un cas particulier.
[^] # Re: Définition
Posté par hervé Couvelard . Évalué à 5.
Mais il est la le problème.
Tout est une représentation, donc le fait que ce soit une représentation n'est pas une manière de discriminer l'un ou l'autre.
Ainsi j'ai bien compris que 11/12/13 est en fait codé 31 31 2F 31 32 2F 31 33 qui lui même doit être écrit sur le disque dans un truc qui ressemble à 010010100101011 (…..) 0100011100011000110001 de la même manière que 9��6���. doit être codé sur le disque dans un truc qui ressemble à 00100101100110 (…) 10010011001100110010. Ainsi il n'y a aucune différence entre 11/12/13 et 9��6��� puisque in fine c'est une suite de 0 et de 1 (mais pas la même).
J'ai très bien compris cela et j'avoue que cela ne me pose aucun soucis. J'ai donc bien compris ce que tu me raconte.
Maintenant ce que j'essaie d'expliquer c'est que lorsque le logiciel écrit 11/12/13 afin d'être facilement lu par un être humain, JE trouve dommage qu'on le retrouve sous la forme 9��6��� car il faut AUTRE CHOSE qu'un simple éditeur de texte pour le lire. J'ai bien compris qu'un éditeur de texte c'est un truc qui transforme 01001010010(…..) en 11/12/13. MAIS il y a une foultitude d'éditeur de texte, sous tous les os, qui savent faire la transformation et il y a une foultitude d'outils qui savent rechercher et trouver dans le format binaire qu'est le texte. ainsi même si j'ai 31 31 2F 31 32 2F 31 33 je sort hexedit (que j'utilise seulement sous la torture) et je vois les 11/12/13. Et dans les cas ou c'est mal encodé, cela ne me dérange pas de voir des trucs sous la forme "c'est franchement pas génial". Et J'ai bien compris qu'il y a des tonnes d'encodage que même mon firefox ne sait pas lire, mais je n'ai pas à travailler avec et je n'ai aucune de mes machines qui en produise, ni aucun de mes contacts
Ainsi le format binaire texte avec lequel je dois travailler est lu simplement sur ma machine sans avoir besoin de truc bien compliqué. (et je ne considère pas que installer un truc soit compliqué). J'ai même des outils et des process de travail qui savent lire les fichiers en question et en tirer des informations. ET c'est un point important pour moi, car j'aime bien être indépendant, je SAIS que je pourrais lire ces fichiers sur la machine d'un pote ou d'un client ou d'un hôtel si je dois faire face à un soucis et que ma machine ne fonctionne pas. Évidemment tous les outils ne seront pas disponibles (et probablement aucun), mais j'imagine que au pire je pourrais faire "chercher" et que je pourrais lire séquentiellement. JE COMPRENDS tout à fait que ce besoin n'est pas utile pour des personnes ayant des millions de lignes de logs (car ils ne peuvent pas les lire "dans le texte"), mais les millions de lignes c'est pas le cas général. ET le format binaire texte est fait de telle manière c'est que si tu coupes le fichier en deux (avec une scie) chaque partie peut être lue, même si toutes les informations ne sont pas dans les deux moitiés.
C'est 2 avantages résilience à la corruption et très largement lisible sur d'autres os/machine est, pour MOI, un point important. Probablement que demain les grep/sed/awk et j'en passe pourront chercher directement dans journald, probablement que demain il y aura des éditeurs journald installable facilement sur tous les os et toutes les machines (pratiquement tous/toutes) et qu'il y aura un mécanisme pour ne pas perdre le fichier complet de log s'il y a une corruption et ce jour là, je suis intimement persuadé que je serais heureux (si je ne suis pas encore mort) de pouvoir bénéficier de toutes les nouvelles qualités de journald. En attendant je suis pas enchanté de le voir se répandre, même si pour le moment il peut produire du fichier texte.
Ensuite, enfin, plutôt, effectivement je serais chaffouin si mon rotate-log compress en tar.xyz et que je n'ai aucun moyen de lire cette compression sur les machines que j'utilise ou que je suis susceptible d'utiliser. et que 99% des machines que je cotoie ne sont pas capable de lire de tels fichiers, et même si cela me fait gagner 12% d'espace disque. ATTENTION, je ne dis pas qu'il ne faut pas passer à tar.xyz, je dis qu'il faut EN MÊME TEMPS donner des outils installables sur plus de 80% des machines en service.
[^] # Re: Définition
Posté par ckyl . Évalué à 6.
Heu ça serait très con, vu que la sortie de journalctl tu peux la filer… A un pipe !
Du côté ce que tu as absolument besoin c'est d'un cat pour ton format de fichier. En pratique ce n'est pas un problème on fait ça tout les jours avec des formats types protobuf, avro, thrift etc.
De l'autre tu peux avoir une suite d'outils spécialisés pour interroger ce format spécialisé.
Mais les deux utilisation ne sont pas exclusives Comme on semble le lire partout ici. Franchement cat serait un alias qui appele là bonne commande que ça serait transparent.
[^] # Re: Définition
Posté par hervé Couvelard . Évalué à 8.
par défaut on peut installer 7z sur un windows,
par défaut windows il peut pas faire grand chose.
[^] # Re: Définition
Posté par Michaël (site web personnel) . Évalué à 10.
Tu peux discuter avec un trombone animé, ce n'est pas négligeable quand-même!
[^] # Re: Définition
Posté par xcomcmdr . Évalué à 1.
Je préfère discuter avec le chien de Microsoft Bob, qui a fait son grand retour triomphale en 2001 dans Windows XP.
Il a plus de conversation que ce connard de Clippy !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Définition
Posté par oinkoink_daotter . Évalué à 2.
Surtout qu'ils lui ont mis une balle dans la nuque en 2007.
Si tu peux encore parler à Clippy en 2015, va te laver les mains, c'est probablement très sale /o\.
[^] # Re: Définition
Posté par xcomcmdr . Évalué à -1.
Et à quand un décompresseur journald pour MS-DOS ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Définition
Posté par hervé Couvelard . Évalué à 2.
Dès que l'on (re)vendra en masse des ms-dos en vente lié avec une machine que tu achètes, même si tu n'en veux pas ?
# ...
Posté par Kerro . Évalué à 6.
Punaise, y'en a qui ont du temps à perdre pour ENCORE troller sur systemd.
Le pire c'est qu'il y a dans le tas de réels arguments dans un sens et dans l'autre. Mais il faut lire 50 commentaires pour trouver une ligne sympa. Donc elle passe à peu près inaperçue.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: ...
Posté par Albert_ . Évalué à 3.
Utilise journald pour regarder dans les logs et trouver le message interessant.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.