Sytoka Modon a écrit 4551 commentaires

Personnellement, je récupère qemu sur

http://www.dad-answers.com/qemu/

Il y a une image réalisée quasiment toutes les nuits. Par exemple

qemu-snapshot-2006-03-30_23.tar.bz2

De même qu'il y a des bouts de boch dans qemu (au niveau du driver de la carte reseau et de la carte vga si mes souvenirs sont bons). Il serait idiot de ne pas reprendre du code qui marche bien et de ne pas en profiter pour l'améliorer au passage.

Je ne sais pas comment Fabrice Bellard à mis en place la virtualisation dans kqemu mais je ne serais pas étonné qu'il se soit inspiré des idées implémentées dans Xen.

Sauf que je crois que c'est nvi l'editeur par défaut sous debian. En effet, nvi est plus proche des bogues de l'original que vim. Mais j'ai vu passer sur une liste debian qu'ils envisagent de remplacer nvi par vim-tiny.

Je ne parle pas d'une debian où tu installes tout. Je parle d'une debian minimale. Si tu installes vim, il prend la place de nvi par défaut car il a une priorité plus élevée (voir le système des update-alternative de debian pour cela).

Qemu et Xen n'ont aucun rapport en tant que projet.

Qemu était (et est toujours) un émulateur, au même titre que boch. Qemu tourne en espace utilisateur (c'est une application standard). Cependant, depuis quelque temps, il y a un module noyau, kqemu, qui permet d'accélérer le code qui tourne en espace utilisateur dans la machine virtuelle (il y en a même un autre qvm86 si mes souvenirs sont bons qui est libre mais moins performant). Conclusion, jusqu'a il y a peu, avec qemu+kqemu, on lancait une machine virtuelle et tout le code des applications dans la machine virtuelle était directement envoyé au CPU de la machine réelle, seul le code du noyau virtuel était émulé (donc aussi tous les appels systèmes que l'on trouve dans une application).

Xen virtualise un système. Ce n'est pas un émulateur. Donc avec Xen, on lance des machines virtuelles et Xen se charge de la répartition des ressources physiques, notament du CPU, pour chacune des machines virtuelles. Dans Xen, le code noyau ainsi que les applications des machines virtuelles sont directement exécutés par le CPU de la machine réelle. En pratique, avec Xen, les applications tournent quasiment aussi vite dans une machine virtuelle que si elles étaient directement exécutés sur une machine normale. Au niveau des serveurs, c'est très intéressant, il vaut bien mieux virtualiser. C'est bien plus souple dans ces conditions.

Maintenant, avec la dernière version de kqemu, on peux faire de la virtualisation complète, même du code noyau ! Donc qemu marche un peu sur les plate-bande de Xen. D'où ma remarque finale et le lien entre les deux projets.

Cependant, il ne faut pas se tromper. En production, avec des machines virtuelles, il faut être capable d'attribuer des ressources aux différentes machines, de superviser en temps réel. Je ne suis pas sur que les deux projets soit comparable de ce point de vue là aujourd'hui.

Je vois que tu limites à la plateforme windows pour ton développement. Tu peux donc prendre des modules Win32:: de perl. Par exemple les Win32::Gui qui utilisent la couche graphique native de Windows (jamais testé, je préfère personnellement perl/tk ou perl/gtk+glade).

Pour ta connection avec Excel via COM, tu as ton bonheur avec Win32::OLE. Ca parle même d'Excel sur la documentation du module OLE (j'avoue que je n'ai pas été plus loin).

http://search.cpan.org/~jdb/libwin32-0.26/OLE/lib/Win32/OLE.(...)

Puisque tu ne connais pas Python, pourquoi tu t'accroches a lui et tu ne fais pas tout en perl. Il y a tout sur le CPAN. Juste un exemple qui m'a pris moins de 5mn a trouver

http://search.cpan.org/~kwitknr/DBD-Excel-0.06/Excel.pm

> ls voulaient implémenter un support (propriétaire) d'Objective-C dans
> GCC...mais comme la GPL impose de libérer le code ils ont plutot
> décidé de

créer java ...

Ben oui, java n'est pas sortis tout seul du chapeau de Sun. Il partageait NexT, ils ont eu java tout seul ;-) Java est clairement le bébé d'ObjectiveC.

C'est vraiment facile de faire une application graphique en perl. Tu peux le faire avec plein de toolkit : gtk, tk...

Je ne connais pas ton cahier des charges mais ce genre de truc est souvent plus simple à faire en langage de script. Va voir sur le CPAN, c'est pas le nombre de paquetage qui manque. Tu peux même attaquer ton fichier excel avec du SQL si mes souvenirs sont bon (voir les modules DBD/DBI). Pour la partie graphique, tu peux aussi la charger depuis l'API glade.

Ce qu'il te faut, c'est dibs

http://www.csua.berkeley.edu/~emin/source_code/dibs/

Je n'ai pas encore testé, c'est dans ma liste des taches à faire...

Lire pour la derniere URL

http://www.gnu.org/software/sather/docs-1.2/tutorial/iterators1034.html

C'est la aussi ou on voit toute la puissance des itérator de Sather. En Sather, les classes ont des attributs, des méthodes et des itérators. Le gros avantage est de pouvoir itérer sur plusieurs iétrateurs dans une même boucle et le compilateur peux optimiser en mettant toute la partie initialisation en dehors de la boucle. L'autre gros avantage, il n'y a plus de structure for, while until ! Inutile, dépassé. for devient l'iterator upto! sur les entiers

for (i=1, 1000) {....} 

devient

loop
  1.upto!(1000)
  ....
end

Idem pour while

while (test) {....}

qui devient

loop
  while!(test)
 ...
end

L'itérator while! est appellé sur aucun objet. En fait, on pourrait le mettre sur un objet booléen #BOOL, true ou false et considérer que cette notation n'est que du "syntatic sugar". Bref, tout un tas de structure devienne bien plus simple avec cette notion d'itérator.

• http://www.gnu.org/software/sather/docs-1.2/tutorial/iterato(...)

La contruction de l'itérator while! est très simple (les autres aussi), en voici un exemple d'implémentation

while!(pred:BOOL) is
   -- Yields as long as 'pred' is true
   loop
      if pred then
         yield;
      else
         quit;
      end;
   end;
end;

Si on s'authorise l'opérateur ? : du C, cela raccourci carrément le code

while!(pred:BOOL) is
   loop
      pred ? yield : quit;
   end;
end;

• http://www.gnu.org/software/sather/docs-1.2/tutorial/iterato(...) l

Qui a dis que l'algo de la stegano était libre ? Comme ce code ne te sers a rien, il n'y a aucune raison que tu le connaisse. Cela n'empeche pas la lecture du film ni sa copie. Ca permet juste de tracer chaque copie de film de manière unique a la sortie de l'usine. D'ailleurs, je suis sur qu'il y a u truc d'équivalent sur les billets de banque et cela ne gène personne.

Et même si l'algo de stegano était libre, comme tu ne sais pas ce qui est codé, par exemple ta clef publique chiffré par la clef privé de l'usine, ca t'avance a quoi. Je croyais, j'ai peut être tords, qu'il y avait des procédés de stéganographie inviolable aujourd'hui (inviolable au même sens que l'algorithme RSA dans un autre domaine).

Mais depuis que j'ai fait pour premier post, j'ai l'impression que mon idée est identique a ce qu'ils appellement watermarking.

Génial, faut que j'essaye ca ;-)

Dans le systeme présenté ci-dessus, le serveur chiffre avec la clef publique de l'utilisateur. Cependant, rien ne l'empêche a ce moment la de mettre une clef unique par stéganographie ;-) Du coup, retrouver la source devient beaucoup plus facile, chaque film diffusé étant unique.

Je crois que le Perl est plus récent que le C++ ;-)

Quitte a parler du java et du C#, t'aurais pu évoquer le petit frère du C++, l'ObjectiveC, qui en ai la grande source d'inspiration.

> Perso je pense que ça peut être bien pratique.

C'est vrai que c'est pratique mais avec du recul, c'est pratique pendant combien de temps ? Combien coute de faire des "restart" ? Au bilan, tu acceptes de diminuer ta sécurité pour un problème annexe, qui ne peux pas être, a ma connaissance, dé-activé.

Sinon, nous sommes d'accord, gconf en fait bien plus que ce pour quoi il est appeller : les fichiers de configuration.

Le propre d'UNIX est la séparation des taches. A cause de ce gconf qui en fait trop, gimp n'utilise pas gconf.

Moi, ca me gonfle qu'ekiga utilise gconf pour ces parametres (/A priori/, il ne partage rien avec les autres). Ca m'oblige a avoir un daemon gconfd qui tourne.

Idem, si je fais mon propre programme. Je ne veux pas forcement avoir un daemon gconfd qui soit associé a mon programme. D'ailleurs, pour mes fichiers de configuration, j'utilise le format YAML qui est très simple et répond parfaitement au cahier des charges.

Bref, j'aime beaucoup de programmes fait avec les librairies gtk et gnome mais je n'ai pas envie d'avoir toute l'artillerie de gnome derrière pour un simple problème de configuration de mes applications (remarque, c'est pareil avec les application kde). Je ne veux pas être enfermer a choisir soit les applications gnome ou les applications kde. Je veux pouvoir piocher et utiliser les applications qui me plaisent. Bref, la base gnome a un peu trop tendance a t'enfermer dans son environnement.

Je reprends, cvs gère les fichiers binaires, il faut mettre l'option -kb. Ce que je ne me souviens plus, c'est si il garde chaque version, j'avais le souvenir qu'il ne gardait que la dernière.

subversion gère aussi parfaitement les méta-données. Pour les fichiers binaires, il les détecte automatiquement et n'en conserve que les xdelta de différence.

Bref, subversion est très robuste, simple.

Si tu veux un mode local, tu peux utiliser la surcouche décentralisé svk qui marche aussi très bien.

Les autres gestionnaires de versions, je ne les connais pas trop mais j'ai souvent eu l'impression qu'ils sont plus orientés code source que subversion. Par exemple, les gestionaires basé sur la notion de patch sont super bien pour améliorer le développement de code source, ca oblige a dissocier les modfications que l'on apporte en fonction d'objectif clair. L'idée derrière est de pouvoir appliquer les patch dans un autre ordre, et c'est généralement possible.

Dans le cas de fichier binaire, on est obligé de suivre l'ordre des "commit". La notion de patch a donc moins d'intérêt il me semble.

A propose de gconf, il y a des paramètres dans gconf qui sont pris en charge instantanément. Ce n'est pas le cas des fichiers de configuration. Si tu modifie la configuration d'Apache par exemple, il faut lui envoyer le signal HUP pour qu'il recharge a chaud sa configuration. C'est le "restart" des anciens Window Manager basé sur le génial fvwm.

Dans un environnement gnome moderne, tu change un paramètre a un endroit et ca change partout instantanément. C'est beau mais je pense que c'est une mauvaise idée.

Le concept des UNIX est très simple. Des processus ayant des variables d'environnement qu'ils transmettre a leur fils, JAMAIS l'inverse ! Un fils a très peu de pouvoir sur un père (et réciproquement). Il faut mettre en place des outils de plus haut niveau pour faire communiquer les processus (segment de mémoire partagé...)

Pour en revenir a gconf, s'il ne remplacais que les fichiers de configuration, pourquoi tourne-t-il en mode daemon. Ce serait une simple librairie dynamique que le programme chargerait au démarrage, que ce serait très bien.

Le problème est que gconf sers aussi a partager des données entre le programmes et ce n'est pas son rôle, en tout cas, je ne suis pas de cet avis. En plus, le nombre de paramètre a partager est très faible devant la quantité de paramètre spécifique à chaque programme. Bref, que ce rôle revienne à une autre application, pourquoi pas au D-BUS...

A mes souvenirs, cvs écrases l'ancienne version binaire par la nouvelle.

Par contre, subversion fait bien tout cela. Pourquoi cherche tu autre chose sachant que tu en parles dans ta question ?

PS : par contre, ce serait bien que subversion versionne les archives (zip, tar, gz...) en versionnant leur contenu et non en global.

Je suis entouré de gens lambda et ils ne passent pas leur vie au bureau a changer les paramêtres de leur bureau !

Si ils utilisent un bureau a distance via xvnc, tu peux leur préparer un bureau bien configuré sous icewm (comme ca ils ne sont pas trop perdus) et t'as gagné un paquet de ressources.

Avoir un utilitaire graphique qui t'aide a paramétrer, pourquoi pas. Mais faut pas non plus en faire une condition éliminatoire.

Je suis d'accord que ma phrase sur gconf était un peu hors sujet. J'ai deja pas mal posté sur gconf et je maintiens que ce truc n'est pas bon et que c'est un equivalent des variables globales. D'ailleurs, il y a un daemon gcond qui tourne en permanence (meme que parfois, ce co. survie a une fermeture de sessions...).

Personnellement, ca fait longtemps que je suis passé sur une base debian. Sur cette base la, a ma connaissance, il n'y a pas 50 gestionnaire de paquet, quel que soit la distribution. Par ailleurs, il m'arrive da faire mes propres .deb car c'est plus facile à déployer ensuite sur un gros parc de machine.

Donc, je ne vois pas le problème que tu invoques, surtout que j'avais parlé de faire une API commune. Après, que chaque distribution fasse ses propres paquetages avec ses numéros de version, c'est autre chose et cela n'a rien a voir avec le gestionaire lui même.

Malheureusement, il n'y avait aucune blague dans mon post.

Dans la fonction publique, tu es soumis à la règle des marchés, tu n'as donc pas le choix de ce que tu achètes. DELL a perdus le marché des serveurs au CNRS et c'est NEC qui l'a. Cela veut dire que si tu achètes via le CNRS, tu te retrouves avec une machine NEC, ou alors, faut justifier que NEC ne propose pas ce que tu souhaites.

Cependant, NEC a l'air assez ouvert même si leur matériel est surtout validé pour RedHat et Novell (et Windows). Tous les moyens sont donc bons pour qu'il s'ouvre encore plus et valide un plus grand nombre de distribution, notament une base différente que la RedHat.

Il en ai de même avec pas mal de logiciels propriétaires : matlab, comsol (ex femlab)... Si tu ne les installes pas sous RedHat ou Novell, tu perds le support, et ceci même si ca marche très bien.

Quelqu'un pourra m'expliquer cette folie de se faire chacun ses commandes pour installer les rpm ? urpmi, apt2rpm, yum... Pourquoi ils ne travaillent pas ensemble ?

C'est si dur que cela que de décrire un cahier des charges et une API et de partager ensuite le développement ?

sauf que debian ne les sors pas officiellement ! Et puis,les debian se mettent a jour sans CD d'une version a une autre... Bref, ca n'a rien a voir.

On m'a refilé un serveur sous fedora, j'attend la panne matériel pour le reformater sous debian. Rien à voir, mais si il y a du monde dans la salle, vous pouvez comme moi titiller NEC a propos de debian qui a le marché serveur au CNRS. A chaque fois que je les ais au bout du fils, je leur en parle.

Personnellement, j'utilise pwm car je ne veux pas de barre de titre ayant la largeur de la fenêtre... Cependant, je ne bidouille pas mon environnement TOUS les jours ! J'ai personnellement un script qui a tous les paramêtres qui vont bien, je le lance au démarrage et c'est bon. Les rares fois ou je veux modifier un paramêtre, je "restart" mon gestionaire de fenêtre.

Désolé mais le tout graphique avec du gconf en variable globale... c'est bien un peu mais des choses simples, c'est bien aussi.