Debian et la FSF, j'ai l'impression que c'est je t'aime moi non plus depuis le début.
Debian a sa propre définition du libre via les DFSG. Debian n'a jamais considéré la GNU FDL comme une licence libre (il y a des paragraphes a ne pas utiliser si on veut pouvoir mettre la doc dans un paquet debian).
Mark Shuttleworth a été développeur Debian avant de partir dans l'espace. Tant qu'il sera à la tête d'Ubuntu, je ne pense pas qu'il fera un fork de Debian car dans ses interview, il a toujours un grand respect pour Debian je trouve.
C'est dramatique si systemd est un et un seul programme qui tourne avec le PID=1 ! Le PID=1, c'est un peu comme le compte root, c'est un programme à part qu'on ne relance jamais... Il est très important qu'il y ai le moins possible de mise à jour de sécurité sur ce programme par exemple sinon on va se retrouver dans le situation de Windows à devoir rebooter en permanence (cela s'est amélioré).
Dans mes scripts d'init, j'ai aussi une cible status qui me dis un peu plus que ca marche ou pas. Souvent, je fais un cible init a utiliser une fois la première fois... Bref, avoir un vrai langage est un plus.
Simplifier les scripts d'init est effectivement une bonne chose. Avoir un shell réduit comme dash pour Debian est une bonne voie. Enrober tout cela d'un "runit" serait mieux. Un init en petite brique permet de changer une brique par une autre, de rajouter des briques non prévu au début (gestion des cgroup qui n'était pas au programme il y a 10 ans)...
Je viens de m'amuser à faire un
( cd /etc/init.d ; wc * | sort -n )
La grande majorité des scripts sous debian fait moins de 150 lignes en comptant les commentaires. On pourrait faire quelques factorisation ici ou la mais c'est globalement propre. Ce qui est un peu crade coté programmation, ce sont les meta commande INIT INFO en commentaire dans ce même fichier. D'un autre coté, c'est aussi la technique utilisé par les gestionnaires de batch sur les machines de calcul...
Bref, simple, robuste et ouvert sur les innovations du futur
A mon sens, ce sont surtout les USA qui foutent la merde coté unité. Il est vrai que moi-jour-année, c'est illisible et surtout illogique, mais leur miles, galons, farenheit, pouce, peid... et j'en passe. Nos enfants passent leur temps au primaire à apprendre des règles idiotes d'ortografe française (chous, caillous, hibous...) mais les petits américains doivent perdre leur temps à changer les unités pour faire des calculs.
Les anglais roulent à gauche. Sur les voitures, ils ont perdus mais sur les trains, ils ont gagné, les trains roulent à gauche sauf le métro qui roule à droite ! A noter que les USA ont inversé si je me souviens le sens de circulation gauche droite mais je ne me souviens plus quand. Coté mondial, je ne connais pas la proportion droite/gauche. En asie, une partie des voitures a le volant à droite même s'il roule à droite, je crois que ce sont des voitures d'occasion japonaise....
Sur une machine de calcul, on utilise les CPUSET et les CGROUP pour tuer tout ce qui reste d'un job après que le walltime soit terminé. La problématique ici est la même donc comme dis ci-dessus, les CGROUP permettent de faire le boulot.
Sinon, le CACHE de socket, cela ne permet pas de mettre en cache les données pour le serveur syslog en attendant qu'il se lance ;-)
J'ai pas regarder systemd de près mais si c'est bien le processus PID=1 qui fait tout cela, ça craint ! J'espère qu'il se fork ou qu'il envoie des petits...
sysvinit sous debian gère le lancement parallèle des services. D'ailleurs, je crois que c'est une version qui provient à la base de Suse.
Sinon, comme dis dans un autre post, il y aussi la voie très intéressante qui avait été lancé avec runit (et socklog) sur des idées d'ailleurs à la base de D. J. Bernstein (daemontools)
L'idée de base semble dans le même esprit mais découpé en plein de petit programme faisant une et une seule chose... L'idée fondamentale est d'avoir un programme initial "/sbin/init" (PID=1) le plus petit possible ce qui me semble dans la logique même...
Je ne vois pas pourquoi les programmes "modernes" s'évertuent à vouloir par défaut être en mode serveur et à tout regrouper dans une seule instance ce qui est problématique en cas de plantage (iceweasel, geany...).
Les IHM qui écrivent les fichiers perdent souvent les commentaires, l'indentation... Je sais qu'il y en a qui y arrive mais c'est pas le plus courant. Le dernier exemple qui me passe par la tête est backuppc qui fait un dump de l'objet config et donc perds tous tes commentaires (d'ailleurs, c'est pas nickel nickel d'avoir fait un dump mais bon).
Ceci dis, l'exemple que tu prends n'est pas le plus facile. J'ai quelques fichiers /etc/network/interfaces qui définissent plus de 20 interfaces réseaux et peut être qu'un interface.d aurait été pas mal. D'ailleurs, le fichier qui me pose le plus de soucis à gérer automatiquement pour le moment est /etc/ssh/sshd_config. Dommage qu'on ne puisse inclure les fichiers d'un dossier dedans car comme c'est un fichier TRES sensible, c'est toujours délicat de faire des grosses modifications dedans !
Et que dire des autres architecture que debian supportent ... qui souvent d'ailleurs bloque la sortie de la distribution.
L'aspect multi-arch et multi-OS permet d'être plus robuste avec des API claire, stable et identifié pour la plupart. Cela donne aussi du temps au temps. C'est parfois énervant mais c'est aussi important. Ceci dis, il ne faut pas non plus s'ankyloser, il y a un temps pour tout !
Ce que j'aime bien dans un système UNIX, c'est qu'il y a plein de bout en script au coeur du système, c'est donc assez facile d'intervenir dessus et de l'adapter. C'est aussi une grande force anti-virale... J'aimerais bien que PAM par exemple soit plus facilement scriptable qu'actuellement.
J'ai déjà pris l'exemple du serveur SMTP Qpsmtpd programmé en langage de script. Très facile d'aller y modifier un truc ou deux alors que c'est quasiment impossible à un admin système de base comme moi si c'était un Postfix ou un Exim.
Il est vrai qu'un coeur en script, c'est pas forcément la joie pour les GUI ;-) Sinon, il y a un outil assez sympa, Config::Model, qui pars sur l'idée que plutôt que de vouloir tout uniformiser, tout normaliser, la diversité peux avoir du bien donc c'est à la surcouche de s'adapter. Personnellement, je ne l'utilise pas car vi me suffit dans 99% des cas.
Un système binaire peut à mon avis être intéressant dans le cas de forte charge mais avec un nombre d'entrée pré-définit. une base de type RRD à rotation automatique permet alors un accès direct en écriture. Cela pourrait aussi être un backend à syslog et pourrait servir par exemple pour des log de firewall...
Sinon, les GUI pour lire les log sont tout sauf pratique. C'est bon pour les petits dépannage du genre un installateur d'un soft Windows qui au premier click téléphone déjà a sa hotline ;-) Jamais pu utilisé les journaux Windows tellement c'est peu pratique...
Si j'ai bien compris une partie des débats, un des problèmes majeurs est que syslog n'est pas lancé en premier donc que faire en attendant que syslog soit opérationnel ? systemd ne pourrait pas ouvrir le port le syslog, écouter et tamponner en RAM (ou ailleurs) en attenant que syslog démarre et reprenne le tout ? J'ai cru comprendre que systemd était capable de maintenir les descripteurs de fichier lors d'un redémarrage de service ?
En https, de plus en plus les navigateurs mettent le nom de domaine ou plus précisément la fin du nom de domaine. Je n'aime pas cela car cela revient à simplifier l'arbre DNS avec un seul sous domaine.
Sauf que en pratique, je gère le domaine "machin.linuxfr.org" de manière autonome et que je n'ai, au final, que peu à voir avec "linuxfr.org". Que le www saute car il représente le nom de la machine, pourquoi pas, mais pourquoi faire sauter une partie du nom DNS de domaine ?
Exact, à part un ingénieur en instrumentation qui ne supportais pas LabView, tous les autres expérimentateurs ont fait ce choix là. Du coup, le marché est captif pour National Instrument. En interne, la gestion des versions des différents programmes de pilotage est du coup ... folkorique. Si quelqu'un sais comment gérer de manière simple dans le temps et de manière collaborative les programmes LabView, je suis preneur.
De plus en plus de chercheur utilisent Python à la place de Matlab (ou Octave ou Scilab...). On se retrouve cependant avec le même problème que la suite MS Office, c'est jamais compatible à 100%. Si c'est la suite elle-même (ou Matlab), la non compatibilité d'une version à une autre passe mieux...
Ne pas avoir confiance totale dans une boite ne signifie que tout ce qu'elle fait est de la merde ;-) Pourquoi de suite prendre une position extrême ?
Par ailleurs, dans les exemples que tu donnes, il y a une différence entre aider à maintenir un système et développer un nouveau système... Par exemple, les débuts de network-manager ont été très difficile, l'outil était beaucoup trop lié au fait d'avoir une IHM graphique.
Avec le temps et tous les contributeurs, les outils se bonifient ou trouvent des remplaçant, c'est tant mieux ;-)
Je parle de mon labo car c'est plus intéressant que chez moi, il y a un peu plus de poste à gérer... C'est pas juste un truc avec 10 machines. L'informatique personnelle, un PC = une IP = une personne ne m'intéresse pas particulièrement.
Sinon, j'aime effectivement bien le Perl (et le CPAN), plus que Python par exemple mais je déploie aussi des trucs en Python, PHP... Quand au dev, je n'en fais plus beaucoup mais je préfère poser des questions parfois candides puis changer d'avis ensuite s'il le faut.
Tiens, ca m'intéresse de savoir quelques grosses conneries que j'aurais dites car je ne doute pas d'en avoir dis quelques unes ;-) Au moins, je pourrais me faire un coup d'auto-dérision lundi à la pause café !
Ca parait simple mais cela met tout sur un seul processus... Via la séparation, le démon de relance pourrait être dans un cgroup différent par exemple. L'idée en soi est assez séduisante je trouve.
Et puis, depuis quand l'utilisateur final s'intéresse à la tripotée de démon qui tourne ? L'architecture du processus numéro 1 ne me semble pas avoir une quelconque interaction directe avec l'utilisateur.
C'est sur que sur tous mes serveurs, je passe mon temps à accéder à la ligne 100000 des fichiers de log !
Perl est capable de trouver cette ligne très rapidement et c'est pas une action vraiment utile en temps réel sur un OS standard... Que sur un serveur central de log, cela soit utile, OK, mais on peux alors utiliser un backend SQL spécialisé...
Combien de service démarre avant rsyslogd ? C'est le problème de la poule et de l'oeuf... Ni a t'il pas un moyen de gérer cela d'une autre manière. Par exemple, ces applications enverraient leur log au noyau donc klogd tant que syslogd n'est pas actif. Tout remettre en cause et rendre les choses incompatible pour quelques secondes me semble excessif.
J'utilise monit pour relancer les services qui crash. Ca marche... On aurait pu améliorer monit !
Monit permet de dissocier le démarrage de la supervision des services eux-mêmes.
Un des principes d'UNIX, faire une chose et le faire bien. Je trouve personnellement que systemd en fait trop et j'aime pas trop son connecteur DBUS. Pour un processus aussi sensible, cela fera la joie du vers un jour...
Format libre = souplesse au cours du temps. Des outils comme Perl parse cela sans problème...
Date -> bordel -> timestamp
Base données mysql -> bof. Je verrais plutôt une base de taille fixe à la RRD s'il fallait changer ou plutôt donner le choix !
Non compatibilité avec syslog -> débile
Problème au démarrage -> je croyais qu'il y a avait klogd pour ca.
...
Syslogd n'est pas parfait. Plutôt que de faire des améliorations, on change tout ! Ca va être un produit conçu à la mode du moment. Red-Hat a déjà foutu des fichiers XML de config à droite et à gauche, c'est bien pour les IHM payante de gestion de parc mais c'est loin, très loin d'être parfait. Bref, j'ai pas une confiance à 100% dans tout ce que fait Red-Hat (d'ailleurs, j'ai quitter les distributions Red-Hat il y a plus de 10 ans pour justement des problèmes de conception).
Idem, je ne sais pas vraiment comment marche le son sur mon PC mais je ne vois aucun truc en puseaudio. Je précise qu'il y a toujours 2 sessions en // par deux utilisateurs différents. J'ai rien modifié, tout marche tout seul (Debian Squeeze).
Je ne crois pas trop au tout espace utilisateur pour les drivers...
Par contre, avec la virtualisation qui s'invite de plus en plus partout, le "nettoyage" par le noyau d'un driver foireux sera de plus en plus facile à faire en restant en mode noyau. Xen par exemple explore cette piste en mettant certain driver dans des dom0 prime (cela reste pour le moment de l'ordre de la recherche je crois).
J'ai pas compris son problème avec la sécurité. Tu envois tes log sur un serveur central qui est blindé...
Si effectivement, toute ton architecture est une passoire, les log ne serviront à rien.
Sinon, la souplesse d'UNIX est de faire des choses simples, souples et orthogonales. A force de trop vouloir normalisé, il va finir par trop contraindre l'ensemble qui n'arrivera pas à évoluer au cours du temps et devra être remplacer un jour par autre chose car il aura oublié de traiter un cas particulier.
[^] # Re: titre
Posté par Sytoka Modon (site web personnel) . En réponse au journal Chute des valeurs du logiciel libre et perte d'influence de la FSF. Évalué à 4.
Debian et la FSF, j'ai l'impression que c'est je t'aime moi non plus depuis le début.
Debian a sa propre définition du libre via les DFSG. Debian n'a jamais considéré la GNU FDL comme une licence libre (il y a des paragraphes a ne pas utiliser si on veut pouvoir mettre la doc dans un paquet debian).
http://fr.wikipedia.org/wiki/Principes_du_logiciel_libre_selon_Debian
Debian a sa propre structure financière qui sers d'ailleurs à d'autres projets : la SPI.
[^] # Re: Debian is dying, tué par ubuntu
Posté par Sytoka Modon (site web personnel) . En réponse au journal Chute des valeurs du logiciel libre et perte d'influence de la FSF. Évalué à 5.
Mark Shuttleworth a été développeur Debian avant de partir dans l'espace. Tant qu'il sera à la tête d'Ubuntu, je ne pense pas qu'il fera un fork de Debian car dans ses interview, il a toujours un grand respect pour Debian je trouve.
[^] # Re: NOTRE héros Lennart Poettering (parmi d'autres)
Posté par Sytoka Modon (site web personnel) . En réponse au journal Lennart casse les logs!. Évalué à 4.
C'est dramatique si systemd est un et un seul programme qui tourne avec le PID=1 ! Le PID=1, c'est un peu comme le compte root, c'est un programme à part qu'on ne relance jamais... Il est très important qu'il y ai le moins possible de mise à jour de sécurité sur ce programme par exemple sinon on va se retrouver dans le situation de Windows à devoir rebooter en permanence (cela s'est amélioré).
Dans mes scripts d'init, j'ai aussi une cible status qui me dis un peu plus que ca marche ou pas. Souvent, je fais un cible init a utiliser une fois la première fois... Bref, avoir un vrai langage est un plus.
Simplifier les scripts d'init est effectivement une bonne chose. Avoir un shell réduit comme dash pour Debian est une bonne voie. Enrober tout cela d'un "runit" serait mieux. Un init en petite brique permet de changer une brique par une autre, de rajouter des briques non prévu au début (gestion des cgroup qui n'était pas au programme il y a 10 ans)...
Je viens de m'amuser à faire un
( cd /etc/init.d ; wc * | sort -n )
La grande majorité des scripts sous debian fait moins de 150 lignes en comptant les commentaires. On pourrait faire quelques factorisation ici ou la mais c'est globalement propre. Ce qui est un peu crade coté programmation, ce sont les meta commande INIT INFO en commentaire dans ce même fichier. D'un autre coté, c'est aussi la technique utilisé par les gestionnaires de batch sur les machines de calcul...
Bref, simple, robuste et ouvert sur les innovations du futur
[^] # Re: Décalage UTC
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Tchatche LinuxFr.org : l’espace de rédaction. Évalué à 2.
A mon sens, ce sont surtout les USA qui foutent la merde coté unité. Il est vrai que moi-jour-année, c'est illisible et surtout illogique, mais leur miles, galons, farenheit, pouce, peid... et j'en passe. Nos enfants passent leur temps au primaire à apprendre des règles idiotes d'ortografe française (chous, caillous, hibous...) mais les petits américains doivent perdre leur temps à changer les unités pour faire des calculs.
Les anglais roulent à gauche. Sur les voitures, ils ont perdus mais sur les trains, ils ont gagné, les trains roulent à gauche sauf le métro qui roule à droite ! A noter que les USA ont inversé si je me souviens le sens de circulation gauche droite mais je ne me souviens plus quand. Coté mondial, je ne connais pas la proportion droite/gauche. En asie, une partie des voitures a le volant à droite même s'il roule à droite, je crois que ce sont des voitures d'occasion japonaise....
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par Sytoka Modon (site web personnel) . En réponse au journal Lennart casse les logs!. Évalué à 3.
Sur une machine de calcul, on utilise les CPUSET et les CGROUP pour tuer tout ce qui reste d'un job après que le walltime soit terminé. La problématique ici est la même donc comme dis ci-dessus, les CGROUP permettent de faire le boulot.
Sinon, le CACHE de socket, cela ne permet pas de mettre en cache les données pour le serveur syslog en attendant qu'il se lance ;-)
J'ai pas regarder systemd de près mais si c'est bien le processus PID=1 qui fait tout cela, ça craint ! J'espère qu'il se fork ou qu'il envoie des petits...
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par Sytoka Modon (site web personnel) . En réponse au journal Lennart casse les logs!. Évalué à 4.
sysvinit sous debian gère le lancement parallèle des services. D'ailleurs, je crois que c'est une version qui provient à la base de Suse.
Sinon, comme dis dans un autre post, il y aussi la voie très intéressante qui avait été lancé avec runit (et socklog) sur des idées d'ailleurs à la base de D. J. Bernstein (daemontools)
http://smarden.org/runit/
L'idée de base semble dans le même esprit mais découpé en plein de petit programme faisant une et une seule chose... L'idée fondamentale est d'avoir un programme initial "/sbin/init" (PID=1) le plus petit possible ce qui me semble dans la logique même...
Je ne vois pas pourquoi les programmes "modernes" s'évertuent à vouloir par défaut être en mode serveur et à tout regrouper dans une seule instance ce qui est problématique en cas de plantage (iceweasel, geany...).
[^] # Re: Point de vue rétro-actif de noob.
Posté par Sytoka Modon (site web personnel) . En réponse au journal Lennart casse les logs!. Évalué à 2.
Les IHM qui écrivent les fichiers perdent souvent les commentaires, l'indentation... Je sais qu'il y en a qui y arrive mais c'est pas le plus courant. Le dernier exemple qui me passe par la tête est backuppc qui fait un dump de l'objet config et donc perds tous tes commentaires (d'ailleurs, c'est pas nickel nickel d'avoir fait un dump mais bon).
Ceci dis, l'exemple que tu prends n'est pas le plus facile. J'ai quelques fichiers /etc/network/interfaces qui définissent plus de 20 interfaces réseaux et peut être qu'un interface.d aurait été pas mal. D'ailleurs, le fichier qui me pose le plus de soucis à gérer automatiquement pour le moment est /etc/ssh/sshd_config. Dommage qu'on ne puisse inclure les fichiers d'un dossier dedans car comme c'est un fichier TRES sensible, c'est toujours délicat de faire des grosses modifications dedans !
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par Sytoka Modon (site web personnel) . En réponse au journal Lennart casse les logs!. Évalué à 6.
Et que dire des autres architecture que debian supportent ... qui souvent d'ailleurs bloque la sortie de la distribution.
L'aspect multi-arch et multi-OS permet d'être plus robuste avec des API claire, stable et identifié pour la plupart. Cela donne aussi du temps au temps. C'est parfois énervant mais c'est aussi important. Ceci dis, il ne faut pas non plus s'ankyloser, il y a un temps pour tout !
[^] # Re: Point de vue rétro-actif de noob.
Posté par Sytoka Modon (site web personnel) . En réponse au journal Lennart casse les logs!. Évalué à 4.
Ce que j'aime bien dans un système UNIX, c'est qu'il y a plein de bout en script au coeur du système, c'est donc assez facile d'intervenir dessus et de l'adapter. C'est aussi une grande force anti-virale... J'aimerais bien que PAM par exemple soit plus facilement scriptable qu'actuellement.
J'ai déjà pris l'exemple du serveur SMTP Qpsmtpd programmé en langage de script. Très facile d'aller y modifier un truc ou deux alors que c'est quasiment impossible à un admin système de base comme moi si c'était un Postfix ou un Exim.
Il est vrai qu'un coeur en script, c'est pas forcément la joie pour les GUI ;-) Sinon, il y a un outil assez sympa, Config::Model, qui pars sur l'idée que plutôt que de vouloir tout uniformiser, tout normaliser, la diversité peux avoir du bien donc c'est à la surcouche de s'adapter. Personnellement, je ne l'utilise pas car vi me suffit dans 99% des cas.
[^] # Re: Bonnes questions, mais…
Posté par Sytoka Modon (site web personnel) . En réponse au journal Lennart casse les logs!. Évalué à 2.
Un système binaire peut à mon avis être intéressant dans le cas de forte charge mais avec un nombre d'entrée pré-définit. une base de type RRD à rotation automatique permet alors un accès direct en écriture. Cela pourrait aussi être un backend à syslog et pourrait servir par exemple pour des log de firewall...
Sinon, les GUI pour lire les log sont tout sauf pratique. C'est bon pour les petits dépannage du genre un installateur d'un soft Windows qui au premier click téléphone déjà a sa hotline ;-) Jamais pu utilisé les journaux Windows tellement c'est peu pratique...
Si j'ai bien compris une partie des débats, un des problèmes majeurs est que syslog n'est pas lancé en premier donc que faire en attendant que syslog soit opérationnel ? systemd ne pourrait pas ouvrir le port le syslog, écouter et tamponner en RAM (ou ailleurs) en attenant que syslog démarre et reprenne le tout ? J'ai cru comprendre que systemd était capable de maintenir les descripteurs de fichier lors d'un redémarrage de service ?
[^] # Re: Idée rapide
Posté par Sytoka Modon (site web personnel) . En réponse au message depends.sh. Évalué à 4. Dernière modification le 20 novembre 2011 à 17:16.
Sans boucle et en monoligne... Je suis juste passé par ldd. Pourquoi utilises tu objdump ?
# Idée rapide
Posté par Sytoka Modon (site web personnel) . En réponse au message depends.sh. Évalué à 2.
Solution simple
./depends.sh /bin/bash | sort -u
# HS
Posté par Sytoka Modon (site web personnel) . En réponse au journal Mozilla, son cycle de développement de 6 semaines et Eletrolysis. Évalué à 1.
En https, de plus en plus les navigateurs mettent le nom de domaine ou plus précisément la fin du nom de domaine. Je n'aime pas cela car cela revient à simplifier l'arbre DNS avec un seul sous domaine.
Exemple virtuel :
https://www.linuxfr.org -> linuxfr.org
Sous domaine
https://www.machin.linuxfr.org -> linuxfr.org
Sauf que en pratique, je gère le domaine "machin.linuxfr.org" de manière autonome et que je n'ai, au final, que peu à voir avec "linuxfr.org". Que le www saute car il représente le nom de la machine, pourquoi pas, mais pourquoi faire sauter une partie du nom DNS de domaine ?
[^] # Re: Tout faux
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Entretien avec Linus Torvalds sur ZEIT ONLINE. Évalué à 2.
Exact, à part un ingénieur en instrumentation qui ne supportais pas LabView, tous les autres expérimentateurs ont fait ce choix là. Du coup, le marché est captif pour National Instrument. En interne, la gestion des versions des différents programmes de pilotage est du coup ... folkorique. Si quelqu'un sais comment gérer de manière simple dans le temps et de manière collaborative les programmes LabView, je suis preneur.
De plus en plus de chercheur utilisent Python à la place de Matlab (ou Octave ou Scilab...). On se retrouve cependant avec le même problème que la suite MS Office, c'est jamais compatible à 100%. Si c'est la suite elle-même (ou Matlab), la non compatibilité d'une version à une autre passe mieux...
[^] # Re: Problèmes de Syslog
Posté par Sytoka Modon (site web personnel) . En réponse au journal Lennart casse les logs!. Évalué à 3.
Ne pas avoir confiance totale dans une boite ne signifie que tout ce qu'elle fait est de la merde ;-) Pourquoi de suite prendre une position extrême ?
Par ailleurs, dans les exemples que tu donnes, il y a une différence entre aider à maintenir un système et développer un nouveau système... Par exemple, les débuts de network-manager ont été très difficile, l'outil était beaucoup trop lié au fait d'avoir une IHM graphique.
Avec le temps et tous les contributeurs, les outils se bonifient ou trouvent des remplaçant, c'est tant mieux ;-)
[^] # Re: Problèmes de Syslog
Posté par Sytoka Modon (site web personnel) . En réponse au journal Lennart casse les logs!. Évalué à 9.
Je parle de mon labo car c'est plus intéressant que chez moi, il y a un peu plus de poste à gérer... C'est pas juste un truc avec 10 machines. L'informatique personnelle, un PC = une IP = une personne ne m'intéresse pas particulièrement.
Sinon, j'aime effectivement bien le Perl (et le CPAN), plus que Python par exemple mais je déploie aussi des trucs en Python, PHP... Quand au dev, je n'en fais plus beaucoup mais je préfère poser des questions parfois candides puis changer d'avis ensuite s'il le faut.
Tiens, ca m'intéresse de savoir quelques grosses conneries que j'aurais dites car je ne doute pas d'en avoir dis quelques unes ;-) Au moins, je pourrais me faire un coup d'auto-dérision lundi à la pause café !
[^] # Re: systemd
Posté par Sytoka Modon (site web personnel) . En réponse au journal Lennart casse les logs!. Évalué à 3.
Ca parait simple mais cela met tout sur un seul processus... Via la séparation, le démon de relance pourrait être dans un cgroup différent par exemple. L'idée en soi est assez séduisante je trouve.
Et puis, depuis quand l'utilisateur final s'intéresse à la tripotée de démon qui tourne ? L'architecture du processus numéro 1 ne me semble pas avoir une quelconque interaction directe avec l'utilisateur.
[^] # Re: systemd
Posté par Sytoka Modon (site web personnel) . En réponse au journal Lennart casse les logs!. Évalué à 2.
J'ai jamais dis que c'était facile.
Si c'est un bête SIGCHLD, pourquoi ne pas le rajouter au processus init actuel ? Il fait comment en cas de fork ?
[^] # Re: systemd
Posté par Sytoka Modon (site web personnel) . En réponse au journal Lennart casse les logs!. Évalué à 2.
Qu'est ce qui empêcherait monit ou mon d'être notifier directement ?
[^] # Re: Problèmes de Syslog
Posté par Sytoka Modon (site web personnel) . En réponse au journal Lennart casse les logs!. Évalué à 3.
C'est sur que sur tous mes serveurs, je passe mon temps à accéder à la ligne 100000 des fichiers de log !
Perl est capable de trouver cette ligne très rapidement et c'est pas une action vraiment utile en temps réel sur un OS standard... Que sur un serveur central de log, cela soit utile, OK, mais on peux alors utiliser un backend SQL spécialisé...
Combien de service démarre avant rsyslogd ? C'est le problème de la poule et de l'oeuf... Ni a t'il pas un moyen de gérer cela d'une autre manière. Par exemple, ces applications enverraient leur log au noyau donc klogd tant que syslogd n'est pas actif. Tout remettre en cause et rendre les choses incompatible pour quelques secondes me semble excessif.
[^] # Re: systemd
Posté par Sytoka Modon (site web personnel) . En réponse au journal Lennart casse les logs!. Évalué à 6.
J'utilise monit pour relancer les services qui crash. Ca marche... On aurait pu améliorer monit !
Monit permet de dissocier le démarrage de la supervision des services eux-mêmes.
Un des principes d'UNIX, faire une chose et le faire bien. Je trouve personnellement que systemd en fait trop et j'aime pas trop son connecteur DBUS. Pour un processus aussi sensible, cela fera la joie du vers un jour...
[^] # Re: Problèmes de Syslog
Posté par Sytoka Modon (site web personnel) . En réponse au journal Lennart casse les logs!. Évalué à 7.
Aller au 100 message -> ligne 100
Format libre = souplesse au cours du temps. Des outils comme Perl parse cela sans problème...
Date -> bordel -> timestamp
Base données mysql -> bof. Je verrais plutôt une base de taille fixe à la RRD s'il fallait changer ou plutôt donner le choix !
Non compatibilité avec syslog -> débile
Problème au démarrage -> je croyais qu'il y a avait klogd pour ca.
...
Syslogd n'est pas parfait. Plutôt que de faire des améliorations, on change tout ! Ca va être un produit conçu à la mode du moment. Red-Hat a déjà foutu des fichiers XML de config à droite et à gauche, c'est bien pour les IHM payante de gestion de parc mais c'est loin, très loin d'être parfait. Bref, j'ai pas une confiance à 100% dans tout ce que fait Red-Hat (d'ailleurs, j'ai quitter les distributions Red-Hat il y a plus de 10 ans pour justement des problèmes de conception).
[^] # Re: systemd
Posté par Sytoka Modon (site web personnel) . En réponse au journal Lennart casse les logs!. Évalué à 3.
Idem, je ne sais pas vraiment comment marche le son sur mon PC mais je ne vois aucun truc en puseaudio. Je précise qu'il y a toujours 2 sessions en // par deux utilisateurs différents. J'ai rien modifié, tout marche tout seul (Debian Squeeze).
[^] # Re: Avis de Linus Torvalds sur les micro-noyaux
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Entretien avec Andrew Tanenbaum à propos de MINIX. Évalué à 2.
Je ne crois pas trop au tout espace utilisateur pour les drivers...
Par contre, avec la virtualisation qui s'invite de plus en plus partout, le "nettoyage" par le noyau d'un driver foireux sera de plus en plus facile à faire en restant en mode noyau. Xen par exemple explore cette piste en mettant certain driver dans des dom0 prime (cela reste pour le moment de l'ordre de la recherche je crois).
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par Sytoka Modon (site web personnel) . En réponse au journal Lennart casse les logs!. Évalué à 4.
J'ai pas compris son problème avec la sécurité. Tu envois tes log sur un serveur central qui est blindé...
Si effectivement, toute ton architecture est une passoire, les log ne serviront à rien.
Sinon, la souplesse d'UNIX est de faire des choses simples, souples et orthogonales. A force de trop vouloir normalisé, il va finir par trop contraindre l'ensemble qui n'arrivera pas à évoluer au cours du temps et devra être remplacer un jour par autre chose car il aura oublié de traiter un cas particulier.