Sytoka Modon a écrit 4551 commentaires

C'est pareil sous debian squeeze (sauf que j'ai changé cela via polkit sur les postes utilisateurs et que ma config polkit fonctionne bien).

Ici, le cas est différent, je ne suis pas dans une session démarré via gdm ou équivalent. Il n'y a aucune session locale. D'ailleurs, ni gdm (gdm3, kdm), ni gnome-session ne sont installé sur le poste car il s'agit d'un serveur en rack (en pratique, il y en a plusieurs).

Les sessions s'ouvrent via NX (freenx + nxclient). Du coup, j'ai un comportement que je ne comprends pas… Je pense que c'est du à la procédure de lancement ainsi qu'aux classements des sessions dans console-kit mais à dire vrai, je n'en sais rien !

Je n'utilise pas GNOME via NX car tant GNOME que KDE mette à plat n'importe quelle machine dès qu'on a plusieurs utilisateurs… On a donc juste besoin d'un window manager léger pour ne faire que quelques opérations graphiques. Pour des raisons de 3D, un ssh tout simple n'est pas satisfaisant (Ansys merde grave par exemple selon le client). Via NX, la 3D a lieu sur le serveur et les choses dépendent bien moins du poste client.

C'est pas un peu finit cette pub. C'est pas l'esprit de ce site. Si tu as une nouvelle à faire, fais là une bonne fois pour toute mais ne saucissonne pas en 3000 morceaux…

Un pub de temps en temps sur le sujet, OK, mais là, c'est l'overdose ;-)

PHP, PHP… Ca existe encore ce truc ;-)

Je parlais plus particulièrement du cas d'un langage dont le développement est communautaire donc avec un 'CPAN' central.

Au niveau des logiciels privateurs orienté calcul, c'est la fin du 32 bits. En tout, c'est annoncé pour Matlab, idem pour Ansys (sauf que ce dernier est une vrai daube avec un paquet de binaire PE32 tournant sous mono… un scandale).

Toi aussi, tu n'est pas objectif, cela veut dire quoi "le plus libre possible" ? Implicitement, tu as fait un classement a cet endroit. Tu aurait pu mettre "code piquable par les industriels"… Bref, les mots ont un sens sociologique.

Sinon, je ferais au niveau GPL trois classes :

• bibliothèque intégrable dans un logiciel propriétaire mais dont les modifications doivent rester libre -> LGPL

• code dont les modifications reste libre lors d'une diffusion -> GPL (link fort)

• code devant rester libre même en cas d'utilisation client serveur (web) -> AGPL (link faible)

A cela s'ajoute tes deux catégories BSD / Apache que tu as parfaitement résumé.

Enfin, selon les langages, il est préférable parfois de prendre la licence par défaut utiliser par le langage. Par exemple en Perl, on prendra la licence Artistic le plus souvent.

Tu peux mettre des Duplo sur des Lego mais pas l'inverse il me semble. La compatibilité n'est alors pas de 100%…

Et ils ont raison ;-) Un logiciel libre doit pouvoir être adapté à une distribution sans que les développeurs amont soient obligé de valider chaque patch…

La solution trouvée satisfait les deux parties mais elle ne serait pas généralisable à tous les logiciels libre !

De toute manière, Debian fait un gros boulot coté licence et a toujours été pénible avec l'amont sur ce point sans faire de cadeau (cf les soucis avec la FSF a propos de la FDL par exemple). Le bon coté est que cette position a obligé pas mal de projet a avoir une licence claire ;-)

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 !