Et non. Comme précisé plus bas je ne voulais pas dire RedHat et Fedora mais "les distrib qui ont réussi à intégrer des trucs comme pulseaudio sans vrai problème".
C'est à dire ni Ubuntu (gros gros soucis, c'est eux que Lennart donne econre comme le mauvais example), ni Debian (18 mois pour être accepté), ni mandriva (moribonde à l'époque c'est vrai), ni suse (crash en pagaille, et pourtant ce sont eux les créateurs d'alsa), ni Slackware (qui n'en veut pas). On va dire que CentOS ne compte pas et que Gentoo ne l'a pas vraiment intégré en tant que tel mais que c'est liè au format même de la distrib.
Il reste qui ? Quelle distrib a intégré PulseAudio sans gros soucis ?
Je rappel que ce que tu as dis c'est : ce qui limite l'utilisateur et l'empêche de faire des choses exotiques On parle donc bien de l'utilisateur, pas simplement des autres programmes qui tournent.
Oui PA limite l'utilisateur et l'empêche de faire des choses exotiques. Maintenant ca lui permet à la place d'en faire d'autre. Par exemple on ne peut plus faire d emixage hard ou de mixage sources croisées ou trop différentes, mais on peut renvoyer le son sur son oreillette bluetooth. One ne peut plus faire de temps réel mou ou de synchro jack aux petits oignons, mais on peut créer un tunnel réseau qui prend même pas 50% de CPU. On ne peut plus greffer un plugin ladspa générique à tous les périphs entrant MIDI et écouter le résultat en temps réel en 5.1, mais on peut créer un filtre ladspa gstreamer sur une appli donnée avec même pas 40ms de latence.
Alors après que les ajouts et améliorations ne t'intéressent pas spécialement en fait on s'en fiche un peu, le fait est que ça intéresse suffisamment de monde et que ça règle suffisamment de problèmes pour que toutes les distrib ou presque utilisent PA.
Je suis entièrement d'accord, c'est d'ailleurs pour ça que je me bats tous les jours pour le retour d'IE 5.5 - Parceque ca résolvait suffisament de problème et que ca interressait suffisament de monde pour que tous les sites web ou presque soient compatibles exclusivement IE 5.5
Ok, mais dans ce cas il n'y a rien qui conviennent vraiment. Et avoir un outil unique pour faire tous ces cas différent c'est justement l'inverse d'un outil pour une action donnée le tout chainable.
C'est à se demander qui le fait exprès. Quand j'ai un format générique de log qui respecte la philosophie Unix je peux utiliser TOUS les outils et TOUS les devices qui respectent cette philosophie pour arriver au résultat.
Par exemple je peux faire tcpdump -F /mon/fichier/log ou encore tar -cvf backup.tar log1 log2 log3 ou encore des jointures compliquées entre plusieurs fichiers avec des ID de forensic (CF mod_log_forensic apache).
Si lumberjack ne respecte pas la philo Unix, il y aura forcément des opérations que je ne pourrais plus faire, des effets de bord, des collisions. Donc j'en veux pas.
_Rien que ça. Tu as regardé pour de vrai ou tu es juste intimement persuadé que c'est le cas. _
J'invente c'est plus simple. Sans rire, tu n'as pas légèrement l'impression que je me suis documenté sur Lumberjack un minimum ? Non ?
Si on prend par exemple le fait que le créateur de rsyslog bosse sur lumberjack, y'a quand même de quoi se poser des questions, non ?
Non. Ca serait l'inventeur du système de log, ou d'un format de log particulièrement pointu je ne dis pas. Mais rsyslog malgré toutes ses qualités est une amélioration dans la continuité, Lumberjack est une rupture.
Non non, comme tu dis, il n'est pas fait pour greper un log il est fait pour greper un contenu texte.
Il est fait pour grepper un fichier. Et comme tout est fichier dans Unix… Tu peux lui faire grepper un socket si tu veux, perso je le fait même assez régulièrement. grep toto /dev/urandom ca marche….
Et donc si tu as un catlog qui te sort juste les messages de log alors ton grep fonctionnera toujours.
Déjà cat sert à concatener, si c'est pour un seul fichier on utilise autre chose normalement et ensuite même si j'avais un
Le truc dans l'histoire c'est que tu oublie totalement la structuration des données du log. Et ça, désolé, mais c'est une vrai fonctionnalité manquante.
Je ne l'oublei pas, je le trouve ridicule. Des appli différentes qui font des choses différentes avec des informations dfférentes et des buts différents ne peuvent pas toutes avoir le même format de log. On est juste en train d'ajouter un peu d'enrobage (que personnellement j'ai déjà en ce qui concerne le timestamp et la machine émétrice) à des données qui ne sont pas réconciliables. Le même format de log pour les connexions HTTP, les dump TCP, les traitement d'images et les vectorisations GCGPU ? Même pas en rève. On va juste mettre un emballage autour de l'info qui m'interresse. Emballage qu'il me faudra défaire à chaque fois.
Et c'est pas unix. Au fait, tu confondrais pas unix avec bordel bas niveau ?
La liberté c'est l'esclavage, l'ordre dans les règles Unix c'est le bordel bas niveau. La réthorique à 2cents c'est ici.
[^] # Re: Où est le problème ?
Posté par Kaane . En réponse au journal Quelle distribution restera dans l'esprit UNIX?. Évalué à 6.
Et non. Comme précisé plus bas je ne voulais pas dire RedHat et Fedora mais "les distrib qui ont réussi à intégrer des trucs comme pulseaudio sans vrai problème".
C'est à dire ni Ubuntu (gros gros soucis, c'est eux que Lennart donne econre comme le mauvais example), ni Debian (18 mois pour être accepté), ni mandriva (moribonde à l'époque c'est vrai), ni suse (crash en pagaille, et pourtant ce sont eux les créateurs d'alsa), ni Slackware (qui n'en veut pas). On va dire que CentOS ne compte pas et que Gentoo ne l'a pas vraiment intégré en tant que tel mais que c'est liè au format même de la distrib.
Il reste qui ? Quelle distrib a intégré PulseAudio sans gros soucis ?
Je rappel que ce que tu as dis c'est : ce qui limite l'utilisateur et l'empêche de faire des choses exotiques On parle donc bien de l'utilisateur, pas simplement des autres programmes qui tournent.
Oui PA limite l'utilisateur et l'empêche de faire des choses exotiques. Maintenant ca lui permet à la place d'en faire d'autre. Par exemple on ne peut plus faire d emixage hard ou de mixage sources croisées ou trop différentes, mais on peut renvoyer le son sur son oreillette bluetooth. One ne peut plus faire de temps réel mou ou de synchro jack aux petits oignons, mais on peut créer un tunnel réseau qui prend même pas 50% de CPU. On ne peut plus greffer un plugin ladspa générique à tous les périphs entrant MIDI et écouter le résultat en temps réel en 5.1, mais on peut créer un filtre ladspa gstreamer sur une appli donnée avec même pas 40ms de latence.
Alors après que les ajouts et améliorations ne t'intéressent pas spécialement en fait on s'en fiche un peu, le fait est que ça intéresse suffisamment de monde et que ça règle suffisamment de problèmes pour que toutes les distrib ou presque utilisent PA.
Je suis entièrement d'accord, c'est d'ailleurs pour ça que je me bats tous les jours pour le retour d'IE 5.5 - Parceque ca résolvait suffisament de problème et que ca interressait suffisament de monde pour que tous les sites web ou presque soient compatibles exclusivement IE 5.5
Ok, mais dans ce cas il n'y a rien qui conviennent vraiment. Et avoir un outil unique pour faire tous ces cas différent c'est justement l'inverse d'un outil pour une action donnée le tout chainable.
C'est à se demander qui le fait exprès. Quand j'ai un format générique de log qui respecte la philosophie Unix je peux utiliser TOUS les outils et TOUS les devices qui respectent cette philosophie pour arriver au résultat.
Par exemple je peux faire tcpdump -F /mon/fichier/log ou encore tar -cvf backup.tar log1 log2 log3 ou encore des jointures compliquées entre plusieurs fichiers avec des ID de forensic (CF mod_log_forensic apache).
Si lumberjack ne respecte pas la philo Unix, il y aura forcément des opérations que je ne pourrais plus faire, des effets de bord, des collisions. Donc j'en veux pas.
_Rien que ça. Tu as regardé pour de vrai ou tu es juste intimement persuadé que c'est le cas. _
J'invente c'est plus simple. Sans rire, tu n'as pas légèrement l'impression que je me suis documenté sur Lumberjack un minimum ? Non ?
Si on prend par exemple le fait que le créateur de rsyslog bosse sur lumberjack, y'a quand même de quoi se poser des questions, non ?
Non. Ca serait l'inventeur du système de log, ou d'un format de log particulièrement pointu je ne dis pas. Mais rsyslog malgré toutes ses qualités est une amélioration dans la continuité, Lumberjack est une rupture.
Non non, comme tu dis, il n'est pas fait pour greper un log il est fait pour greper un contenu texte.
Il est fait pour grepper un fichier. Et comme tout est fichier dans Unix… Tu peux lui faire grepper un socket si tu veux, perso je le fait même assez régulièrement. grep toto /dev/urandom ca marche….
Et donc si tu as un catlog qui te sort juste les messages de log alors ton grep fonctionnera toujours.
Déjà cat sert à concatener, si c'est pour un seul fichier on utilise autre chose normalement et ensuite même si j'avais un
Le truc dans l'histoire c'est que tu oublie totalement la structuration des données du log. Et ça, désolé, mais c'est une vrai fonctionnalité manquante.
Je ne l'oublei pas, je le trouve ridicule. Des appli différentes qui font des choses différentes avec des informations dfférentes et des buts différents ne peuvent pas toutes avoir le même format de log. On est juste en train d'ajouter un peu d'enrobage (que personnellement j'ai déjà en ce qui concerne le timestamp et la machine émétrice) à des données qui ne sont pas réconciliables. Le même format de log pour les connexions HTTP, les dump TCP, les traitement d'images et les vectorisations GCGPU ? Même pas en rève. On va juste mettre un emballage autour de l'info qui m'interresse. Emballage qu'il me faudra défaire à chaque fois.
Et c'est pas unix. Au fait, tu confondrais pas unix avec bordel bas niveau ?
La liberté c'est l'esclavage, l'ordre dans les règles Unix c'est le bordel bas niveau. La réthorique à 2cents c'est ici.