Mais alors comment ont fait les distrib qui ont réussi à intégrer des trucs comme pulseaudio sans vrai problème ?
Tu veux dire Red Hat et Fedora ? Ben en fait Lennart travaille pour eux, c'est pour ça.
C'est quand même marrant, c'est exactement l'opposé de PulseAudio. Pire que ça, en général ceux qui se plaignent disent que les fonctionnalités apportées ne servent à rien.
Non ce n'est pas l'opposé de Pulse Audio. Pour les applis (ie pour les autres programmes qui tournent) Pulse Audio est supposé simplifier la connexion audio. Après qu'il fasse autre chose en aval c'est son problème.
En ce qui concerne les fonctionnalités qui ne servent à rien, c'est plus généralement des fonctionnalités qui existaient déjà avant.
C'est fantastique comme solution \o/ Pulse Audio est encore compatible avec netcat. Je pense que ca sera corrigé dans une version ultérieure mais pour l'instant c'est le top.
Donc si je résume je créé une interface pulse audio en local, je la streame en local, je renvois le stream dans un netcat et de là je renvoie sur une machine distante avec une autre interface pulse audio. C'est comme d'envoyer le son directement dans un netcat vers un dsp d'une machine distante sauf que l'on est limité en fréquence et en précision à 44100hz/16bits. Merci de m'ouvrir les yeux sur ce formidable outil.
Mais en quoi c'est opposable ? Si greplog te balance ce qu'il convient dans la sortie standard il est où le problème ?
greplog ne peut pas balancer ce qui me convient, parcequ'il n'est pas sentient. Des fois ce qui me convient c'est de passer le log dans du tcpdump, des fois c'est de grepper, des fois c'est de faire un tail -f, des fois c'est de passer par un parser XML, des fois c'est même de rediriger le log vers un tty. A la limite un catlog qui serait capable de gérer parfaitement le binaire ca se discute, mais pourquoi rajouter une étape de plus (que je paye cher en plus, vu que tous les tags XML vont partir à la poubelle à l'analyse mais seront bien présent sur mon disque dur niveau espace pris).
C'est vrai que je pense qu'ils ne vont jamais se poser cette question…
Oh, et je sais même comment ils vont y répondre, on aura une base de donnée linké en statique. En cas de faille la mise à jour se fera de façon assez complexe pour ne pas perdre d'info. Et bien sur pour exporter les logs pour analyse après attaque on aura pleins de petits outils très utiles (eux aussi linké en statique forcément). Bref d'un fichier texte ou binaire brut on va passer à même pas 20 outils linkés en statique et dont la mise à jour nécessitera quelques pirouettes. J'ai hate.
cool tu les aura en json
J'ai hate de désérialiser à la main du json issu automatiquement du XML d'un programme qui buggue.
Ben en l’occurrence j'ai l'impression que beaucoup ferment les yeux devant les problèmes des solutions actuelles parce qu'ils ne comprennent pas / ne maîtrisent pas
Là on est complètement d'accord. Beaucoup de gens ne comprennent pas les problèmes liés aux solutions apportées.
Mais là on dirait que sous pretexte que ça ne respecte pas votre vision d'Unix
C'est pas 'notre' vision d'Unix. C'est la philosophie Unix. Ca fait 40 ans qu'on la pratique elle commence à être plutôt normée et objective comme vision. Et en face on a la vision très personnelle Lennart/Red Hat qui pour le coup est complètement subjective. Donc oui je préfère largement une méthode éprouvée objective et bien comprise du reste du monde à la prolinuxitude selective de Lennart.
Et lorsqu'on dit qu'au contraire il est possible de continuer à respecter la philo unix (par exemple faire un outil dédié, simple et ne faisant qu'une chose comme consulter les logs plutôt que de pervertir un autre)
greplog ne serait pas un outil qui respecterait la philosophie Unix. Ce serait un outil qui ne serait pas chainable en amont vu qu'il ne pourrait traiter QUE les logs lumberjack. Donc j'en veux pas. Je veux pouvoir utiliser les outils standards, les scripts, les redirections sur mes logs, comme je l'ai toujours fait mais surtout comme j'ai besoin de le faire.
Et de plus greper un log ce n'est pas une perversion de grep, il est même fait pour ça (prendre un fichier en entrée et le passer à la moulinette). Même si le fichier en question c'est le flux pulse audio dans netcat dont on parlait plus haut.
[^] # Re: Où est le problème ?
Posté par Kaane . En réponse au journal Quelle distribution restera dans l'esprit UNIX?. Évalué à 10.
Mais alors comment ont fait les distrib qui ont réussi à intégrer des trucs comme pulseaudio sans vrai problème ?
Tu veux dire Red Hat et Fedora ? Ben en fait Lennart travaille pour eux, c'est pour ça.
C'est quand même marrant, c'est exactement l'opposé de PulseAudio. Pire que ça, en général ceux qui se plaignent disent que les fonctionnalités apportées ne servent à rien.
Non ce n'est pas l'opposé de Pulse Audio. Pour les applis (ie pour les autres programmes qui tournent) Pulse Audio est supposé simplifier la connexion audio. Après qu'il fasse autre chose en aval c'est son problème.
En ce qui concerne les fonctionnalités qui ne servent à rien, c'est plus généralement des fonctionnalités qui existaient déjà avant.
Tiens, un journal qui montre justement certains intérêts de pulseaudio : https://linuxfr.org/users/yellowiscool/journaux/transferer-du-son-en-reseau-avec-pulseaudio-vlc-et-un-clavier-bepo
C'est fantastique comme solution \o/ Pulse Audio est encore compatible avec netcat. Je pense que ca sera corrigé dans une version ultérieure mais pour l'instant c'est le top.
Donc si je résume je créé une interface pulse audio en local, je la streame en local, je renvois le stream dans un netcat et de là je renvoie sur une machine distante avec une autre interface pulse audio. C'est comme d'envoyer le son directement dans un netcat vers un dsp d'une machine distante sauf que l'on est limité en fréquence et en précision à 44100hz/16bits. Merci de m'ouvrir les yeux sur ce formidable outil.
Mais en quoi c'est opposable ? Si greplog te balance ce qu'il convient dans la sortie standard il est où le problème ?
greplog ne peut pas balancer ce qui me convient, parcequ'il n'est pas sentient. Des fois ce qui me convient c'est de passer le log dans du tcpdump, des fois c'est de grepper, des fois c'est de faire un tail -f, des fois c'est de passer par un parser XML, des fois c'est même de rediriger le log vers un tty. A la limite un catlog qui serait capable de gérer parfaitement le binaire ca se discute, mais pourquoi rajouter une étape de plus (que je paye cher en plus, vu que tous les tags XML vont partir à la poubelle à l'analyse mais seront bien présent sur mon disque dur niveau espace pris).
C'est vrai que je pense qu'ils ne vont jamais se poser cette question…
Oh, et je sais même comment ils vont y répondre, on aura une base de donnée linké en statique. En cas de faille la mise à jour se fera de façon assez complexe pour ne pas perdre d'info. Et bien sur pour exporter les logs pour analyse après attaque on aura pleins de petits outils très utiles (eux aussi linké en statique forcément). Bref d'un fichier texte ou binaire brut on va passer à même pas 20 outils linkés en statique et dont la mise à jour nécessitera quelques pirouettes. J'ai hate.
cool tu les aura en json
J'ai hate de désérialiser à la main du json issu automatiquement du XML d'un programme qui buggue.
Ben en l’occurrence j'ai l'impression que beaucoup ferment les yeux devant les problèmes des solutions actuelles parce qu'ils ne comprennent pas / ne maîtrisent pas
Là on est complètement d'accord. Beaucoup de gens ne comprennent pas les problèmes liés aux solutions apportées.
Mais là on dirait que sous pretexte que ça ne respecte pas votre vision d'Unix
C'est pas 'notre' vision d'Unix. C'est la philosophie Unix. Ca fait 40 ans qu'on la pratique elle commence à être plutôt normée et objective comme vision. Et en face on a la vision très personnelle Lennart/Red Hat qui pour le coup est complètement subjective. Donc oui je préfère largement une méthode éprouvée objective et bien comprise du reste du monde à la prolinuxitude selective de Lennart.
Et lorsqu'on dit qu'au contraire il est possible de continuer à respecter la philo unix (par exemple faire un outil dédié, simple et ne faisant qu'une chose comme consulter les logs plutôt que de pervertir un autre)
greplog ne serait pas un outil qui respecterait la philosophie Unix. Ce serait un outil qui ne serait pas chainable en amont vu qu'il ne pourrait traiter QUE les logs lumberjack. Donc j'en veux pas. Je veux pouvoir utiliser les outils standards, les scripts, les redirections sur mes logs, comme je l'ai toujours fait mais surtout comme j'ai besoin de le faire.
Et de plus greper un log ce n'est pas une perversion de grep, il est même fait pour ça (prendre un fichier en entrée et le passer à la moulinette). Même si le fichier en question c'est le flux pulse audio dans netcat dont on parlait plus haut.