nud a écrit 898 commentaires

Rien n'empêcherait le développement d'un backend 'interfaces-file' similaire au backend keyfile.

ses utilisateurs savent qu'écrire "!#/bin/sh" signifie "ne pas tester le script uniquement avec zsh, mais avec un shell purement POSIX", contrairement à la majorité des utilisateurs de bash.

Tout simplement parce que leur shell par défaut (/bin/sh) reste souvent bash, et que l'utilisation de zsh reste suffisemment confidentielle pour que s'ils utilisent des zshismes dans leur script, quelqu'un va vite s'en rendre compte.

Il y a peu, bash était le shell par défaut de toutes les distributions linux majeures, mais avec Debian qui utilise dash, par exemple, ça commence à changer... C'est un peu comme les gens qui faisaient des sites web pour IE6 quand il avait 95% de PDM.

filtrer selon certains critères (GREP ou AWK) comme la date, le programme, le client, etc., pour extraire l'information souhaitée

Tu ne fais que reformuler la même chose que moi avec d'autres critères, pour lesquels l'analyse des fichiers log est tout aussi inefficace.

Le bonne solution à ce problème est d'embaucher un vrai admin système.

Oui, parce que le meilleur admin système du monde est capable de prévoir qu'un relai va déconner à un certain moment et remplir les logs à vitesse grand V, sans monitorer la taille de ses fichiers de logs en permanence ?

Par ailleurs, parfois (genre, en cas de machines hostées chez un client) on n'a pas un controle total sur tout ce qui peut se passer en dehors de sa propre sphère d'influence.

rsyslog ne fournit aucun moyen de contrôle et de limitation de la taille des fichiers, et c'est un réel problème, car remplir une partition est un bon moyen de provoquer un DoS. Peut-être que syslog ne pose pas de problème particulier en opérations courantes, mais quand un problème se présente c'est un gros problème. D'ailleurs je citais ici d'un cas qui m'est arrivé, mais il y a une autre façon très simple de faire générer à syslog des gigaoctets de logs: le flood sur le port 514.

Sur FreeBSD avec syslogd, on peut, par configuration et avec l'aide de logrotate forcer une rotation quand un fichier dépasse une certaines taille.

Je peux le faire sous linux aussi avec rsyslog, mais c'est une configuration relativement compliquée qui devrait être très simple vu le risque potentiel. En fait, ce devrait être fait par défaut et être éventuellement un opt-out.

Explique-moi donc comment procéder, si c'est si facile.

Pour info, systemd réagit tout simplement à SIGCHLD.

Rassure-moi, tu ne penses pas réellement qu'implémenter un proxy pour le syslog au niveau du noyau est une meilleure solution, n'est-ce pas ?

J'utilise mon, il marche très bien et il ne fait pas ce que systemd peut faire. Je peux certes vérifier toutes les 30 secondes que mon service tourne (ce qui exige l'exécution d'un script). Mais systemd peut tout simplement redémarrer le service dès qu'il disparaît car il en est notifié directement.

Aller au 100 message -> ligne 100

Et quand tu ouvres un fichier dans un langage de programmation quelconque, tu ne peux pas seeker directement sur la ligne 100, tu dois lire chaque ligne une à une pour repérer les \n. Osef pour la ligne 100, mais la ligne 100000 est déjà plus longue à atteindre, par exemple (exemple assez idiot, on est d'accord) si tu veux faire une interface qui présente les messages de syslog de façon paginée.

Problème au démarrage -> je croyais qu'il y a avait klogd pour ca.

klogd est pour le noyau, mais y'a des services qui démarrent avant rsyslog.

Parce qu'il faut quand même une façon d'identifier l'âge relatif du soft installé. Un commit hash (vu que mozilla utilise mercurial) ne permettrait pas ça, au contraire d'une révision svn.

Il met aussi en avant le fait qu'un programme qui utilise le syslog standard verra son log dupliqué : une fois dans syslog et une fois dans Journal.

C'est seulement vrai pour le support legacy des messages syslog il me semble. Pas pour les messages "journald".

Bon, je reformule.

Certes la plupart des devs de Gnome utilisent Linux, mais tous ne se contrefichent pas des autres plateformes, et la plupart essaient de pondre du code portable et de ne pas dépendre de trucs linux-only. D'ailleurs il y avait pas mal de devs issus de Sun qui travaillaient sous Solaris, mais je crois que Oracle les a (presque) tous virés.

Après tu as la masse des employés de RedHat qui a en fait plutôt intérêt que seul Linux soit supporté, et qui semblent parfois rendre les choses difficiles à dessein. C'est de ceux-là que vient cette idée crétine de "Gnome OS".

Certaines limitations que Lennart mentionne dans son document sont tout à fait connues de tous et une vraie épine dans le pieds de certain.

Morceaux choisis:

• Le fait que le format des messages soit tout à fait libre et sans conventions rend le parsing impossible.
• La lecture des fichiers log est totalement inefficace, il est impossible d'accéder rapidement au 100e message par exemple, ou d'avoir les messages à un moment donné.
• Certains événements importants ne sont pas logués parce qu'ils ont lieu avant le démarrage de rsyslog (corrigé par systemd)
• Les logs prennent vraiment énormément de place. Un petit problème dans postfix (genre un relai défaillant) et on se retrouve vite avec un fichier log de 1GO juste avec les essais ratés de transmission.
• Il est difficile de provoquer une duplication des syslogs sur deux machines, dans les deux sens. Cela fait assez vite exploser la charge.
• Il est difficile de faire en sorte que chacun puisse accéder à ses propres logs.

Cependant, avec rsyslog:

• On peut utiliser un backend différent, comme par exemple MySQL, pour faciliter les requêtes sur les logs (par contre, pas de logs sans MySQL). On pourrait tout aussi bien développer un nouveau backend basé sur sqlite ou autre pour corriger ce problème.
• On peut, par configuration et avec l'aide de logrotate, forcer une rotation quand un fichier dépasse une certaine taille.

Quand je vois son projet, certaines idées sont bonnes, mais d'autres sont assez bizarres ou floues. Le fait d'utiliser un fichier binaire est assez bizarre, et je me demande comment il fait avec un fichier append-only pour avoir un accès aléatoire.

Il faut aussi garder à l'esprit que pas mal de services externes (par exemple des téléphones IP) peuvent balancer leurs propres logs sur un serveur syslog, donc même si on remplace rsyslog il faut continuer à supporter le protocole sur le réseau. Et ça c'est mal parti d'après la FAQ.

Par ailleurs, je ne comprends pas non plus pourquoi il développe ça dans le cadre de systemd, plutôt que de faire un projet séparé. Pour minimiser la maintenance peut-être ?

Ben pour administrer des serveurs assez critiques (de la téléphonie) chez pas mal de clients, y'a quand même des trucs bien intéressants au niveau de systemd, comme le fait qu'il soit capable de redémarrer un service qui se vautre tout seul comme un grand, et qu'il soit capable de ne pas perdre d'information malgré ce crash grâce à sa gestion des fd.

Par contre certains trucs me semblent plus difficiles à débugger, mais c'est peut-être dû au manque d'habitude et de connaissance de systemd.

s/Gnome/RedHat/

Bien sûr que si, avec dmix.

Idem pour Neverwinter Nights qui était loin d'être un petit jeu indie. (Faut dire que le créneau "jeu de rôle" répond pas mal à la culture du geek linuxien). Par contre ils se sont mis l'assez importante communauté NWN linux à dos car la version 2 a été portée sur Direct3D, et Windows only.

Et je ne parle même pas de Quake 3.

Et pourtant tu trouves le temps de commenter sur linuxfr ;-)

Est ce qu'il y a un intérêt à refaire une API embedding ? qui a besoin d'embedding

Si webkit prend de l'importance (et bouffe peu à peu des parts à Gecko) c'est en bonne partie pour ça. Le web ouvert c'est bien, mais le web ouvert uniquement via Mozilla non. Et jusqu'à l'apparition de webkit pas grand monde ne voulait embarquer du gecko quand même (comparativement à embarquer du webkit aujourd'hui).

Ben le truc c'est que ça n'a jamais été facile d'embarquer du gecko, car ce n'était clairement pas fait pour. Ensuite Webkit est arrivé (sans s'presser) et a comblé le besoin de "widget de visualisation HTML all-purposes" et c'est pour ça (simplicité, mais aussi le fait que les devs de gecko s'en foutaient) que les utilisateurs de gecko sont tous passés à webkit... Parmi ces utilisateurs, on trouve epiphany, mais aussi des yelp, devhelp, liferea et similaires.

Donc en résumé il y avait clairement un besoin pour un widget "HTML/Web", et gecko a été utilisé pour tout un temps, mais maintenant webkit a pris la place, et on se dirige vers un web avec quasi-uniquement webkit... (Safari, Chrome, Epiphany, plein de trucs en ligne, plein d'applis tierces, etc.)

Non, car le contournement de la protection est légalement interdit (cf DADVSI)

Ceci contredit la première réponse... sauf si on considère que le téléchargement d'une oeuvre déjà crackée fait partie de la copie priée, ce qui m'étonnerait assez...

Donc, au moins dans le cas de la France, il y a une taxe sur quelque chose qui n'est pas permis. Un peu comme si on avait une taxe prévisionnelle sur le vol ou le meurtre... Ah mais ça existe (sur base volontaire, pas obligatoire), ça s'appelle une assurance...

Il y a une chose que je ne comprends pas bien.

1. Dans la mesure où on paie déjà les droits d'auteurs sur les disques durs, les cartes flash, les lecteurs MP3, les supports optiques vierges et peut-être bientôt sur les connexions internet, pourquoi devrait-on les payer en plus sur les oeuvres proprement dites? Est-ce que cela signifie que, comme l'on a déjà payé les droits d'auteurs, on peut télécharger librement tout contenu protégé sur le net?

2. Ceci n'est pas nouveau, mais la protection des DVD et autres, déjà difficilement défendable juridiquement, est-elle caduque du fait que quoi que l'on fasse, si l'on copie celui-ci on le copie sur un media "right-proof" sur lequel on a déjà payé une redevance ?

3. Suis-je en droit de réclamer de la SABAM ma part des droits d'auteurs sachant que les cartes flashs et les disques durs que j'achète me servent à stocker des photos, du code et des documents que j'ai créés moi-même, et pour lesquels je suis donc le titulaire exclusif des droits d'auteurs ?

http://forensicscontest.com/

J'ai également proposé des corrections, ainsi que des améliorations aux script contribs, tout a été pris en compte, comme quoi la communauté n'est pas mise de côté.

Tu en as de la chance. Le fait que Digium fasse du double-licensing et distribue une version propriétaire prétendument améliorée d'Asterisk, et surtout le fait qu'ils recquièrent une copyright attribution pour accepter un patch rend tout simplement impossible la contribution à Asterisk autre que le report de bugs pur et simple. Alors c'est vrai, même si on contribue à plein de projets, on ne contribue pas à Asterisk. C'est domage mais c'est comme ça que fonctionne le logiciel libre en entreprise.

avez-vous versé un seul centime à Digium pour l'utilisation d'Asterisk ?

Je trouve cette attaque gratuite et déplacée. Ça doit faire 10 ans que je contribue au logiciel libre, en tant que développeur hobbyiste, je n'ai jamais reçu le moindre centime pour la chose alors que d'autres font ou ont fait des sous sur mon code, et je ne viens pas pleurer sur dlfp pour autant.

Il est clair que ce n'est pas simple.

Les problèmes auxquels je faisais allusion sont principalement liés à des problèmes de deadlocks intempestifs et des corruptions de mémoire.

Je suis assez familier avec la complexité d'asterisk vu que je travaille avec "tout nu" depuis la 1.0, donc de ce côté là merci, ça va. Mais je n'oserais pas mettre un 1.8 chez un client comme une zone de police qui se mange des milliers d'appels par jours alors que j'arrive à le faire deadlocker chez moi en quelques heures juste en sip avec du dialplan...

Le problème, c'est qu'avec un programme aussi complexe, un petit changement innocent qui n'a pas été suffisemment testé peut vite avoir des effets de bords inatendus et foutre la merde en bloquant tout... Et il faut avoir confiance en la bête. Je ne nie pas qu'il y ait des fonctionnalités hyper-intéressantes dans 1.8, à commencer par le CEL par exemple, mais pour l'instant la confiance n'y est définitivement pas encore. Il suffit de voir le nombre de correctifs de deadlocks et de problèmes de mémoire dans le changelog de la dernière version "stable" pour s'en rendre compte.

Sauvez des compilos, utilisez sizeof().

En fait ça ne veut rien dire, si le binaire est présent/symlinké dans /sbin et /bin, ça dépend de l'ordre de ton $PATH.

udev n'a pas vraiment remplacé hald... c'est un peu comme si tu disais que alsa a remplacé arts. Il n'y a pas remplacement, il y a juste "cette couche intermédiaire ne sert à rien".

udev a plutôt remplacé devfs et hotplug, et le problème est identique avec sysvinit.