Sytoka Modon a écrit 4538 commentaires

C'est clair que le shell UNIX est au coeur du système et que de très grande partie sont scripté en shell.

Un des problèmes est que Windows ne démarre pas en mode terminal même si j'ai cru voir qu'une version de Vista le pourra. Le problème suivant est je n'ai pas connaissance qu'une seule partie de l'OS soit pour le moment en script. Il y a donc encore du boulot pour avoir un système souple et adaptable facilement.

Sur un UNIX, toute la connaissance que l'on apprend dans le terminal peut ensuite être réutiliser au coeur du système. C'est très positif.

Ce nouveau shell windows, c'est bien mais n'aurait-il pas été plus intéressant pour Microsoft d'intégrer un langage de script existant (et non de shell) à .Net, un langage dont le coeur est objet, je pense à Ruby par exemple, pour ensuite reprogrammer un partie de Windows en script justement.

Personnellement, je bannis awk...

En effet, dès que je commence à avoir de l'awk avec du sed... je considère que Perl est plus adapté et plus maintenable (et non, je programme pas comme un gorais en Perl et oui, on peut faire du Perl lisible).

C'est un peu l'approche de debian

- simple, couche base du système -> bash

- compliqué -> Perl

Il ai vrai que l'on voit aussi de plus en plus de python...

L'objectif d'un shell est aussi d'être interactif, de la à faire des gros programmes... Enfin, si le shell windows remplace à la fois command.exe et le vbs système, je crois que personne ne va pleurer. Sauf que malheureusement, il n'y a pas un portage minimal sur les anciens OS !

Je suis d'accord avec toi.

Le principe de base du shell est d'être unifié avec l'approche fichier d'UNIX.

Donc, on doit tout pouvoir rediriger dans un fichier puis traiter ce fichier plus tard ou balancer dans un pipe. Bref, il n'y a pas de différence entre pipe et fichier.

La, si le pipe n'est pas un "fichier", cela change tout.

C'est vrai qu'on a tendance à balancer dans un fichier en remplacement d'un stockage dans une variable. Mais quand même...

Bref, ce nouveau shell, faut le voir à l'usage.

Si le D-BUS principal tombe et que tous les autres tombent alors, cela perds pas mal de son intérêt ! Cela veut dire que l'on ne peut pas relancer le D-BUS sytème sans perturber les autres violament.

Au niveau fam et gamin, en pratique, cela est remplacé par inotify directement par le noyau. Par contre, on doit pouvoir utiliser D-BUS pour la transmission finale ?

Quand à la fin, que gconf utilise dans le futur D-BUS pour transmette ses informations, pourquoi pas. Mais cela n'a effectivement rien à voir. Un des objectifs de gconf est quand même de centraliser les paramètres de configurations des applications. Après, gconf fait plus que cela mais justement, je fait partie des personnes qui trouve qu'il en fait bien trop ;-) Si D-BUS lui enlève une partie du boulot, tant mieux.

A mon avis, upstart s'adpatera à D-BUS ou mourra ;-)

Personne n'a encore évoqué cette thématique ici donc je donne le coup d'envoi ;-)

Sun a fait très attention à ne pas mettre Solaris sous licence GPL à l'époque mais sous une autre licence, incompatible...

En mettant Java en GPL, ils se coupent un peu l'herbe sous le pied pour renforcer l'intégration de Java dans Solaris ?

Au dela de cela, est-ce une remise en cause à moyen terme de la licence Solaris pour finalement validé la démarche de la FSF au travers de la GPL ?

Je n'en ai pas fait beaucoup mais c'est vrai que cela m'a pris en général ma soirée.

D'un autre coté, je ne la trouve pas si mal cette dépêche.

Un point important à mon sens avec D-BUS est que normalement, cela ne tourne pas en root. Chacun a le sien. Je ne sais pas par contre comment les D-BUS communiquent entre eux ? (Le D-BUS utilisateur est-il client du D-BUS système) Cela est un plus par exemple avec le service 'fam' de notification de mofication de fichier qui devait absolument tourner en root, avec les problèmes que l'on connait pour les périphériques amovibles (il faut voir les astuces qui ont été réalisés sur ce point là à une époque pas si lointaines).

Un autre point important est que D-BUS est un bus de messages et de signaux. Cela n'a donc rien à voir avec un système de variable globale de type base de registre ou gconf. Cela me fait plus penser au système de message à la base d'OpenStep. Or tout le monde sait qu'OpenStep (donc GnuStep) qui fonctionne par message avec un langage objet dynamique (ObjectiveC) a montré depuis des années une souplesse de fonctionnement et d'adaptation aux problèmes avec une API d'une incroyable stabilité.

Je ne sais pas précisement pour la licence Apache mais pour une licence BSD, on peut, à ma connaissance, très bien faire un fork et passer le projet sous GPL.

Donc, si c'est aussi possible pour Apache, on pourrait très bien avoir un Apache3 sous GPL ou, en pratique, seules les nouvelles portions de code seraient réellement en GPL.

BSD est compatible GPL mais pas l'inverse... Un projet BSD peut donc très bien finir en GPL.

En quoi Suse est plus intégrée que Debian ? Je ne parle pas des dérivées de Debian...

Honnètement, la qualité de l'intégration d'une debian stable est impressionante. Je n'ai pas essayé Suse mais sur les autres distributions citées, effectivement, il y a des petits soucis ici ou là.

> C'est un accord gagnant-gagnant pour tout le monde.

Non, c'est un accord gagnant-gagnant pour le monde libre (et tant mieux).

Je ne suis pas sur que cela enchante Borland (delphi) et Microsoft (.Net) pour donner deux exemples.

Ce que thunderbird ne fait pas (mais Claws le fait-il ?), c'est de rajouter dans une réponse le champ Reply-To: avec l'adresse mis à To: dans le courriel original, si celui-ci n'est pas l'adresse par défaut.

Je m'explique. Je reçois des courriels destiné à 'support', mais sur le serveur, support est redirigé vers mon compte 'sytoka'. Bilan, lorsque je répond, c'est sous l'identité sytoka et non support. Cependant, je veux que si la personne réponde, elle le soit à support et non à sytoka... D'ou le champ Reply-To.

Bref, un système de gestion de ticket de type 'rt' résoud ce genre de problématique mais bon, c'est pratique pour une personne d'avoir un 'alias' correspondant à sa fonction sans que cela soit une boite mail à part entière : secretariat, compta...

Je prenais Firefox comme exemple mais cela pourrait être un autre logiciel. En gros, comment ca tient dans le temps ces mises à jour ?

Une question que je me pose et qui est aussi valable pour OCS :
Comment sais il que le logiciel est déjà installé et en cas de mise à jour, comment cela se passe-t-il ?

Je pense par exemple à Firefox qui a souvent des mises à jour. Suffit-il de mettre la nouvelle version de Firefox dans la file d'attente et hop, le système se débrouille soit pour l'installer, soit pour le mettre à jour.

Xen marche très bien. Si tu as des doutes, parle en au CRI de l'université de Nantes (Centre de Ressources Informatique, terme moins pompeux que DSI). Si mes souvenirs sont bons, ils virtualisent 250 serveurs sur 40 machines physiques !

Bon, tout n'est pas du Xen, il y a du vserver. Il faut savoir choisir en fonction de l'application.

Personnellement, je fais fonctionner XP sous qemu avec la virtualisation complète de qemu et cela marche super bien.

Je ne suis pas les listes de diffusion au jour le jour mais j'ai l'impression que cela échange pas mal entre qemu et Xen. Je ne vois pas pourquoi Xen n'arriverait pas à faire ce que fait très bien qemu.

Ce n'est pas parce qu'on n'aime pas Windows qu'il faut dire des bêtises. Soyons objectif, des serveurs sous Windows, il y en a des quantités et qui marchent bien.

Cela dit, si je peux éviter, j'évite...

Il est clair que la virtualisation avec Xen, vserver... apporte aussi un autre type de solution que le Hurd mais finalement pas si éloigné.

Par ailleurs, il faut savoir que la virtualisation résoud aussi un gros problème pour Microsoft vu que sous Windows, tout tourne en root. Avec la virtualisation, Microsoft a une bonne occasion de résoudre ce problème, un service = une machine virtuelle.

Bref, les hyperviseurs ont une force de frappe d'un paquet de développeurs qui sont près à graver une partie de la solution dans le silicium.

Encore une fois, c'est pas forcément le meilleur qui gagne mais ceux qui gagne montrent qu'ils arrivent à s'adapter.

Parce que XP n'existait pas à l'époque ;-)

Par ailleurs, son support s'arrètera avant 2010 ;-(

Bref, on n'aime ou on n'aime pas les centrales mais on n'aime pas XP !

Puisque tu ne dis pas, je me lance ;-)

Il est clair que le Hurd est intéressant mais ne décolle pas. D'un autre coté, l'informatique a bien évolué depuis 15 ans. Quittes à faire autre chose, autant le faire dans un autre langage que le C qui montre quand même ses limites aujourd'hui.

Pourquoi pas dans un langage à prototype qui parait très bien adaptés à la problèmatique. Pourquoi pas en Lisaac ?

Bon, pour faire cela, il faudrait que l'INRIA joue pour une fois vraiment le jeu de l'opensource avec IsaacOS. L'INRIA a une carte à jouer, c'est à elle d'abattre son jeu si elle souhaite pouvoir un jour remplacer sur nos postes le système Linux. Mais qu'elle ne traine pas trop !

Effectivement, c'est surtout l'architecture Intel qui a pour le moment été développé. Cela dit, AMD n'est pas oublié mais arrivera à maturité dans un deuxième temps.

J'avoue que j'ai acheté des nouveaux serveurs à base Xeon à cause de cela ;-)

Justement, les limitations du XML font que dans la question de l'objet et de l'enveloppe, les réponses sont partialles à ce niveau là. C'est dommage.

J'avais donné l'exemple du SQL mais celui du LDAP est aussi très bien. A la différence que LDAP est plus une API et qu'il n'y a pas vraiment de langage. Cependant, si je prends le LDIF, c'est aussi un arbre, très structuré avec des schémas de vérification... Bon, il n'y pas pas les namespace, c'est une erreur.

Enfin, il y en a qui n'aime pas les namespaces, j'ai essayé d'expliqué aux personnes qui développent Lisaac que c'était fondamental pour le succès du langage. /A priori/ sans succès...

Pour en revenir au LDIF, même si c'est bien lisible par l'homme, c'est clairement pas un langage fait pour tapper du texte.

Ton exemple sur le LDAP me parait effectivement très bien. Si les milliers de personnes qui ont bossé sur le XML avait bossé sur le LDAP, on aurait vraiment quelque chose de très bien. Pour avoir un modèle simple, on aurait un ldaplite à l'image de sqllite.

Je n'aime pas tes sous-entendu. Je ne suis pas croyant !

Je te parle ici de fichier de configuration, pas de base de données. Je n'irais pas faire une grosse base de données en YAML, c'est pas l'objectif.

Comme je l'ai dis plus bas, les fichiers de configurations de TomCat sont une horreur. Heureusement qu'une grande majorité de logiciels libre ne suit pas cette tendance. Imagine la configuration de samba en XML ainsi que celle d'Apache !

Ensuite, il faut aussi ramener le XML a sa juste valeur. S'il avait été génial, les wikis n'auraient pas été inventé. Le principe du wiki est le même que celui de TeX, privilégier le texte sur les commandes.

Bref, le XML un peu, c'est bien, le XML partout, c'est trop.

Le principe des attributs était plutôt bon en permettant de séparer la définition de l'objet de son contenu. Le fait que ceux-ci ne soient que des chaines fait que tu mets rapidement tout sous forme d'arbre et donc on perd un peu cette notion du contenu et du contenant qui était un plus.

Sinon, nous sommes d'accord, le XML est une bonne solution dans plein de cas mais pas dans tous. Par exemple, les fichiers de configuration de TomCat sont une horrreur... On a tendance à mettre du XML là ou il n'y en pas besoin.

Je suis plutôt dans le calcul numérique, là on oublie le XML et le HDF est bien plus performant ;-)

Quand au YAML, j'en ai parlé dans un cas spécifique, pas comme remplaçant du XML partout. Pour un fichier de configuration, il est par exemple parfait.

Je ne suis pas d'accord avec toi sur l'histoire de lâge. A chacun ses goùts et ses couleurs. Pour moi, c'est le XML qui est d'un autre âge car si c'est un langage pour la machine, un sosie du LISP pouvait faire cela mieux, un langage binaire portable du type HDF aussi ! Si c'est un langage pour l'homme, on ne peux pas dire que cela soit jouissif de se facir du XML dans un éditeur ou sur une page imprimée.

Bref, les concepts derrière le XML, tout l'environnement qui a été crée autour est effectivement passionnant mais le langage lui même est loin de me plaire.

Attention, lorsque je parle du XML, je parle toujours du langage ASCII, pas des API sur une structure d'arbre ou de graphe. Pour moi, ce sont deux choses bien distinctes. Ces API peuvent très bien être portés sur un autre langage.

A mon humble avis, les défenseurs du XML mélangent trop souvent ces API avec le langage XML lui même.

Je ne suis pas du tout un spécialiste du SQL et j'en fait très rarement. Mais lorsque tu vois une requête SQL, c'est quand même vachement esthétique comme langage. Le XML a coté, c'est quand même brut de fonderie.

Les langages de haut niveau sont quand même fait pour l'homme. Avec le XML, j'ai l'impression de refaire de l'assembleur. C'est amusant, un temps.

> on ne te parlera pas non-plus de formalisme et de méthodologie...

Des grand mots mais le problème reste présent ;-)

Je sais bien qu'avec le XML, tu peux représenter n'importe quel arbre, il y a cependant la manière. Quoi que tu fasses et modélises, tes attributs restent et resteront des chaines de caractères.

Il y a donc tout un tas de cas ou le XML est mal fichu...

Pour ce qui est de la sérialisation, je lui préfère le YAML qui est plus léger et plus lisible. Quitte à avoir un programme qui lit et écrit mes données, autant faire simple.

Par conte, il y a des cas ou il est vraiment pratique. Des cas seulement.

Sauf que les attributs en XML ne sont pas des arbres mais des chaines de caractères alors qu'en LISP, ce sont réellement des arbres !

C'est marrant, les pro-XML ne voient jamais ce défaut. Or pour moi, c'est un défaut majeur du XML et je ne vois pas de solution correcte au problème.

Ne me distes pas de mettre les attributs dans le corps de la balise, il y a une distinction entre les balises du corps et les attributs et les mélanger est rarement une bonne idée (mais un pis aller).

Justement, pour les fichiers de configuration, il y a le YAML. C'est très simple et bien plus léger.

C'est un des cas ou le XML est vraiment mauvais et employé à mauvais essient d'après moi. Le YAML est lisible et modifiable par l'homme et la machine.