Sytoka Modon a écrit 4544 commentaires

Et au final, on connaîtra par coeur la forme des mots, on aura alors des idéogrammes chinois ;-)

Ce qui m'étonne, c'est que DBUS devait être un truc léger pour virer cette couche Bonobo/CORBA qui était bien trop lourde… Ou a été l'erreur si erreur il y a eu ?

Avec socat, on doit pouvoir s'en sortir ;-)

On est 100% serveur Debian Squeeze (donc pas de AD Windows), cela marche avec Seven moyennant une clef de registre avant d'intégrer le domaine.

Pour LDAP, en pratique, le contrôleur de domaine communique directement avec avec le serveur LDAP. Je pense que la couche smbldap est assez fine pour ne pas être forcément essentielle. Je dois avoir encore 4 versions de Debian qui fonctionne encore avec ce domaine Windows !

Pour la doc logiciel, j'aime bien le POD qui est un peu un ancêtre de la syntaxe wiki… Cela fait de la doc qui, liée au 'man', est très efficace… Mais les man se perdent petit à petit ;-(

Le problème du XML, c'est que plutôt que de ce concentré sur le contenu, on se perds dans les balises ;-)

Je préfère 100 fois un document LaTeX ou les balises savent se faire bien plus discrète et on on peux vraiment travailler le fond.

Personnellement, j'ai des idées sur beaucoup de chose (mais pas sur tout) mais j'ai assez souvent changé d'avis par le passé pour le refaire encore une fois si on me donne des bons arguments ;-)

Il y a 10 ans, j'ai acheté des bouquins de XML (dont j'ai mis une partie à la poubelle la semaine dernière), j'ai même fait pas mal de weberie avec un pipeline XML en Perl qui était franchement bien. C'est à partir du XSLT que j'ai commencé à avoir vraiment des doutes si mes souvenirs sont bons. J'ai même cru dans le SOAP !

D'ailleurs, je n'ai jamais compris pourquoi le W3C n'avait pas poussé la logique jusqu'au bout et fait un schéma XML pour le CSS !

Ceci dis, je ne me fais jamais chié avec les fichiers de conf au format .ini (blocage psychologique ?). Tous mes fichiers de conf sont en YAML qui est vraiment très bien pour cela, ou alors, c'est du bash à sourcer… Mais avec du YAML, tu te retrouve dans ton programme avec une variable CONF qui est l'exacte copie en terme d'arbre du YAML, c'est idéal et souvent suffisant dans beaucoup de cas.

Je ne vais pas recopier les réponses de CrEv, on est manifestement sur la même fréquence.

Quand tant de monde font de mauvais choix venant d'origine aussi varié et pas nécessairement en entreprise, il peux être
intéressant de se demander ce à qu'il se passe et de se remettre en question.

Avec des phrases comme cela, on serait tous sous Windows…

On sait tous que c'est rarement le meilleur choix qui gagne ! Je ne vais pas refaire l'histoire car je dois aller faire manger mes stroumpfs mais juste un exemple sur un autre sujet : en 80, il y avait trois processeurs, le x86, le 6502 et le Z80… C'est le x86 qui a gagné a l'époque alors que c'était la pire daube des trois !

Il a donc des pièges un peu partout, certains sont certainement évitable…

Ou ai je dis que le XML avait disparu ;-)

Je sais bien que Java en met partout, peut être pour cela que j'évite au maximum ce langage… Quant à GNOME, je ne suis pas du tout enchanté par sa direction depuis pas mal de temps…

Mais revenons sur le sujet, on parle de message sur une même machine ou sur son réseau local. On parle donc de sérialisation. Il s'agit de message court mais très nombreux (des log). Le traitement tout en RAM semble donc la bonne voie (plutôt que du SAX). En gros, il faut sérialisé une structure de manière efficace et légère.

Le JSON (utilisé par la mouvance NoSQL) ou le YAML sont plus adapté à cela que le XML. Il s'agit ici juste de transport. C'est pas moi qui est contre le XML, c'est toi qui veut le mettre partout ;-)

Pour le XMPP et les flux RSS, on est clairement sur un usage internet, proche du HTML pour les flux RSS. Partir sur du XML n'est pas forcément idiot.

On a vu ce qu'a donné le XML pour les RPC (SOAP), on peux dire que la soupe n'a pas super bien prise avec le temps, les services basculant sur des API souvent plus simple à base de REST de nos jours. De plus, les navigateurs prenant le JSON de base, les services NoSQL vont finir par se passer en grand partie du XML.

Bref, les choses évoluent avec le temps et c'est pas plus mal. Quand au format ISO de fichier un peu statique, un schéma XML est pas plus mal qu'une grammaire BNF ;-) En //, Perl6 se définit via des regex Perl6 !

pvcreate /dev/sda

Bref, pas forcément besoin de GPT avec LVM2…

Il faut savoir que pas mal de nouvelle fonctionnalité ne sont jamais ou très peu testé sur d'autres architecture que le x86… Du coup, l'intégration dans debian prends plus de temps en partie parce que cela bogue tout simplement…

Et puis bon, il y a des trucs qui n'était clairement pas mature… Par exemple, systemd n'est clairement pas mature pour remplacer le système actuel chez debian. Au final, debian et fedora sont bien complémentaire.

Super, des trames réseaux over log, on va pouvoir faire des tunnels avec ça ;-)

Tu remarqueras que ces dernières années même sous Unix on s'est éloigné de la configuration uniquement à base de fichier
textes, c'est à mon avis lié à ces problèmes.

C'est lié à RH et Suse qui vendent du support et des formations ;-)

Avec Java et Tomcat, on a eu droit a du XML partout, NetwokManager au début était très très lié à l'interface graphique… Bref, ils ont développé des trucs qui était conçu pour être manipulés par IHM uniquement.

Combien de boite installe RH sans X11 comme serveur ? Je viens d'acheter un gros NAS, bing, X11 (première chose que j'ai viré) !

Je pense que c'est une culture d'une partie des développeurs d'aujourd'hui qui font l'hyhopthèse X11 ou Web2 à la base de leur produit.

Autre travers que j'ai vu dans les applications web. Par exemple avec TRAC en mode SQLite, les sessions sont gérées dans la même base SQLite que les données ! Donc dès qu'une personne navigue dans ton TRAC, la base SQLite est modifiée. C'est un design pourris, on ne devrait pas stocker la configuration, les données, les sessions et les logs dans la même base. Je fais du lsyncd pour faire un backup RAID1 en temps réel de ma forge pour du PRA simplifié, j'en ai rien à foutre de conserver les sessions en cas de crash… Le fait de tout mélangé est une énorme surcharge réseau qui en pratique complexifie tout et ne sers à rien.

On est en train de suivre l'approche toute pourris de Windows avec sa base de registre ou tout est mélangés… et ou sans IHM, c'est un merdier pour s'y retrouver.

Je crois qu'il faut arrêter avec le XML partout, c'était il y a 10 ans en arrière. Des évènements qui arrive de manière temporelle et régulière, on sens bien qu'une écriture en mode append ligne à ligne, c'est vachement adapté.

Quand au XSLT, c'est de la merde en boite… Cela date encore de l'époque ou on voulait tout faire rentrer dans du XML. C'est vraiment vouloir faire du LISP en moins bien, on est capable de faire un langage à moteur d'inférence un peu plus humain je pense ;-)

Au vu de ce que j'ai vu lors de cette discution, il me semble qu'un envoi vers un serveur central type syslog d'une structure normalisé type JSON, YAML… me semble effectivement mieux qu'une simple chaine. Le mieux est de prendre un format rapide, simple et peu verbeux, c'est la partie réseau qui sera interchangeable…

Ensuite, coté syslog, plusieurs backend sont possible et par défaut, un système compatible avec l'actuel d'un append ligne à ligne dans un fichier d'une structure JSON semble relativement efficace à tout point de vue. Le syslog pourrait rajouter au mesage son timestamp d'écriture en début de structure pour avoir l'ordre chronologique.

Bref, le retour à la ligne gère le temps et chaque ligne est une structure JSON indépendante. Ainsi l'analyse de celles-ci ne prends pas trop de ressource mémoire…

Je ne suis pas sur que 10 ans soit une bonne idée sauf cas spécifique (satellite…). Une maintenance trop longue peux aussi s'avérer un boulet à terme.

Après, la bonne longueur…

Actuellement sous debian insserv (développé par Suse à l'origine) gère les dépendances lors d'une mise à jour et sysv-rc assure le boot parralèle. Par besoin d'Upstart /a priori/ pour cela.

De toute façon, le CamelCase, c'est naze ;-)

Je ne connais pas Python que personnellement je n'apprécie guère, cela ne m'a pas empêché de modifier du Python ou du PHP sur des serveurs…

Le problème ne viens pas du C, il viens que c'est du binaire et qu'il faut donc les sources, recompiler… C'est toute cette chaîne qui fait qu'en pratique, quasiment personne je pense ne modifie en serveur écrit en C.

Sinon pour le bash, c'est pas un langage parfait mais cela pourrait être pire. C'est un langage fait pour la ligne de commande donc avec l'espace comme séparateur. Je le trouve surtout faible coté tableau et table de hachage ;-)

Ou ai je dis que systemd ne le permettait pas ?

Je pense que parfois, un langage spécialisé est top, pas exemple le fichier /etc/network/interface de debian. Il est encore plus top si, comme celui-ci, on peux aussi y mettre du bash (dash) dedans !

Bon, ceci dit, cet argument en faveur de systemd peut être retourner en compensant ce défaut de sysV par une bonne
centralisation des confs, et des "meilleures pratiques" bien respectées. Mouhai, j'ai quant même un doute.

Personnellement, j'ai toujours trouvé que les scripts chez Debian était globalement propre et concis.

Il n'empêche que j'utilise en frontal pour le mail QPSMTPD écrit en Perl qui tient bien la charge et que j'ai pu modifier ici ou la à ma sauce alors que je n'ai jamais modifié et ne modifierais certainement jamais une ligne de code dans exim ou postfix !

Il faut du C pour aller vite et aussi du script pour la souplesse.

Toute la force d'UNIX pour le moment a été de garder de la souplesse aux bons endroits…

Personnellement, je pense que les scripts bash qui servent de fichier init avec des gros morceaux de copier coller sont un
problème.

Cela fait des années qu'il existe une solution simple à ce porblème, la mutualisation du code. Un coup de "source" dans ton fichier bash et tu mutualises pas mal de ligne entre les scripts qui le peuvent.

Chez debian, il y a par exemple en début de script

. /lib/lsb/init-functions

Je dois dire qu'avec le boot parallèle du vieux système init amélioré, cela va déjà très vite…

On perd du temps ou sur un serveur : Le bios surtout…

Le reste, ca va très vite, l'activation du réseau peux ralentir parfois (synchro ntp…) mais tout cela reste négligeable devant le BIOS.

Je me rappelle, à l'époque du début de php, Perl avait déjà DBI et était multi-base… alors que php était plus que crade avec ses instructions natives mysql ! Mais il y a eu easy-php qui installait PHP+Apache+MySQL en deux click. Voila la raison du succès. Un enrobage qui était super facile à diffuser et installer.

Bref, beaucoup d'énergie qui aurait pu aller dès le début dans les projets libres Perl et PostgreSQL ;-) Mais bon, la diversité apporte aussi l'émulation inter-équipe.

Plus ancien que Numpy et toujours dynamique, il y a aussi PDL, une couche numérique au dessus de Perl. C'est très utilisé en BIO d'après ce que je vois passer ici ou la.

D'ailleurs, j'ai basculé toutes mes machine virtuelles XEN 32 ou 64 bits sur un noyau amd64. C'est beaucoup plus simple à gérer et pour le moment, je n'ai pas vu un seul inconvénient à faire cela…