Sytoka Modon a écrit 4544 commentaires

Faire de la 3D à distance par exemple avec VirtualGL.

Tu calcules le résultat 3D en local sur une carte et tu balances le résultat jpeg/png... sur le réseau ensuite.

Dis donc, cela faut carrément bidouille ça !

Précision : Dassault a racheté Euclid si mes souvenirs sont bons mais Matra avait déjà mis en route OpenCascade qui est la suite de Cascade (une peu comme OpenGL <- GL).

Dassault a tué Euclid qui était plus que prometteur. Cependant, dans le contrat de rachat, le consorsium OpenCascade avait interdiction de faire une logiciel de CAO avec cette bibliothèque (il leur aurait en effet facile de refaire Euclid avec).

Bref, je pense que la licence un peu merdique vient de cette origine un peu particulière. Aujourd'hui, je crois qu'on a dépassé la date imite dans la clause initiale et celle-ci pourrait peut-être être modifié.

Ou alors, il se souvienne de leur premier cours de l'ENA ou ils se tappent le théorème d'Arrow (Prix Nobel d'économie - 1972) démontrant l'impossibilité de la démocratie !

D'ailleurs, j'aimerais bien avoir leurs avis sur ce théorème ? Je suis sur que la très grande majorité vont dire qu'ils l'ont complètement oublié !

http://www.quebecoislibre.org/030510-4.htm

http://walidoueslati.unblog.fr/2009/10/18/paradox-darrow-ou-(...)

Sur ce cas la, pas de 3D avec le libre donc c'est aussi une certaine forme de plantage ;-)

Moi je proposerais plutôt Charles H. Moore qui a fait (et continue de faire) un boulot énorme sur les machines à pile, tant coté logiciel que coté matériel dans la seconde moitié de sa carrière. Il a vraiment un parcours original et à mon sens assez rare.

Pour ceux a qui ce nom ne dis absolument rien, c'est l'inventeur du langage Forth qui est un langage à pile en notation polonaise inverse (comme le postscript)

Avec le pilote libre, je n'avais pas de 3D donc cela n'allait pas. Les plantages c'est surtout avec le pilote propriétaire.

Il m'arrivais de mettre le pilote vesa sur n'importe quelle carte en cas de problème et c'est rare que l'utilisateur s'en rende compte en pratique ! Comme quoi beaucoup d'utilisateur demande la 3D mais peu l'utilise.

J'ai aussi essayé des ATI et moi aussi, dans mon laboratoire, cela ne marche pas. C'est lent et cela plante ou alors, il y a des bogues monstrueux. J'en était même arrivé à mettre le driver vesa !

J'avoue que je referais une essai d'ici 6 mois pour voir mais c'est fatiguant alors qu'il est vrai qu'avec une nvidia, c'est pas libre mais ca marche.

2.2.8 qui est par défaut dans debian

J'ai l'impression qu'il suffit d'envoyer un courriel à lwn-AT-lwn.net à chaque nouvelle version du logiciel (bien sur en anglais).

Je pense que pas mal de gros logiciel mettent cette adresse dans leur liste "announce".

J'avoue ne pas utiliser Puppet mais cfengine. Je ne savais pas qu'il y a avait des problèmes de syntaxe avec Puppet. Merci.

Sinon, c'est pas un peu dangereux qu'une machine puisse tout savoir sur les autres dans l'absolue ?

J'avais un peu l'espoir de faire le genre de chose que tu dis avec cfengine au début. Mais, je me suis retrouvé rapidement avec un serpent qui se mord la queue. En gros, soit tu installes un paquet qui indique que le serveur doit être dans un << cluster >> soit tu indiques que la machine est dans le << cluster >> et alors cela installe dessus un certain nombre de paquet.

Bref, avec cfengine, tu peux facilement remonter un fichier sur le serveur et celui-ci peut alors redescendre des fichiers ou autre... C'est vrai que ce n'est pas des "events" temps réels mais je me méfie un peu de l'aspect trop temps réel pour des outils à ce niveau la.

A trop vouloir en faire, cela peut devenir dangereux et surtout j'ai pas trop envie que le fonctionnement temps réel de mes serveurs dépendent trop d'un outil tiers en plein développement. Cela me semble peu intégrable sur le temps.

Du coup, par exemple, cfengine me dépose des fichiers pour cron mais ne fait pas le boulot de cron. Idem pour monit...

Bref, à voir et à suivre dans la durée.

Je suis plus au final dans la mouvance d'avoir un outil simple comme Slaughter de Steve Kemp.

http://www.steve.org.uk/Software/slaughter/

Je sais ce que c'est que REST (j'utilise RT par ailleurs), ce que je ne comprends pas au premier abord, c'est le plus de REST dans chef et surtout ce que cela apporte par rapport à cfengine ou par rapport à puppet.

Mettre du REST pour du REST, cela me reste en travers de la gorge ;-)

Et en pratique, par rapport à cfengine ou puppet (qui est aussi en ruby), c'est quoi le plus ?

Je viens de regarder l'API REST et Knife et je me demande à quoi cela sers vraiment en pratique ? Avec cfengine, toute ma configuration est versionnée et propagée de machine en machine via cfserv. J'ai absolument pas besoin d'interagir avec la couche client serveur, c'est complètement transparent. D'ailleurs, mes règles cfengine sont toujours en deux temps : -1- Copie locale des fichiers cfengine, -2- application locale des règles. Ainsi, même en cas de réseau planté ou même si mes machines se baladent à l'autre bout du monde, cfengine applique toujours la dernière politique sur laquelle il s'est synchronisé.

Bref, je vois pas bien a quoi sers cette API REST dans la vie de tous les jours ici.

C'est pour simplifier.

Simplifier, simplifier, simplifier !

D'ici peu, on aura des setup.exe avec toutes les lib dedans ;-)

Ou python ou...

L'idée est bonne mais pourquoi pas un binding dans un langage de script permettant de tester rapidement un petite application et la basculer ensuite en Vala s'il le faut.

Sinon, la doc est trop segmentée. Il faut faire au moins aller sur 4 pages avant d'avoir un exemple concret. Vu la taille des pages, on doit pouvoir faire une doc avec bien moins de page web.

J'ai rien compris chef !

Je suis allé sur le site de Chef et je dois dire que j'ai rien compris à ta nouvelle ni au site. Je ne dois pas être en forme !

C'est quoi l'objectif : de faire de la configuration automatique de poste comme CFengine et Puppet ?

Je ne vois pas ce que veux dire automatiser son infrastructure ici, ni ce que c'est qu'un recette. Sur leur site, il y a du Cookbook ici et la mais pas un exemple clair pour moi.

Bref, je trouve le chef nébuleux...

Comme quoi, rien ne sers de courir :-)

En quelques mots et pour faire une démonstration par l'exemple, Debian monte une version de sa distribution sur noyau BSD, elle s'appelle Debian GNU/kFreeBSD car contrairement à FreeBSD (et au autre distribution BSD), les outils du coeur de la distribution sont les outils GNU et non BSD (ls, bash, libc, mount, tar... et que sais-je encore).

D'ailleurs, cela a demandé un boulot fou de faire cette distribution pour les personnes de Debian. C'est pas juste une recompilation et cela n'a rien à voir avec un portage d'apt-get sur FreeBSD.

A ma connaissance, ce sera la première distribution GNU/BSD ;-)

En tout cas, cela manque d'un site web.

D'après le site web, c'est /a priori/ du logiciel libre, j'ai vu quelques part que c'est du GPLv2 mais je ne sais plus ou

> open: the core components is licensed under GPLv2, the data collection and presentation
> website is a subscription-based component.

Au niveau langage, j'ai vu du bash et du python.

Sinon, je reste un peu sur ma faim et je ne suis pas sur de l'ouverture de la solution en terme de communauté. Il faut dire que l'heure...

Question, coté pilotage ressource disque partagé, en plus du SAN et de l'iSCSI, avez-vous des pistes coté AoE ?

> par contre je trouve la traduction de Firefox en breton fort peu utile.

Une certaine tradition dis que ce qui est inutile est donc fondamental ;-)

Mais je dirais que si on veux que ces petites langues ne meurent pas, il faut bien qu'elle vive avec leur temps. Et puis, les personnes qui travaillent la dessus ne travaillerait pas forcément sur d'autres traductions... Donc, je dirais que c'est enrichissant.

Par contre, c'est à terme la mort des différents bretons.

J'en profite pour savoir si vous connaissez un truc tout bête du genre :

- stockage de paire clef-valeur

- redondance sur disons 3 serveurs (ou plus)

- tolérant aux pannes d'un des trois serveurs

- rapide et facile d'utilisation

- utilisable sous Perl et de préférence avec "tie"

En gros, aujourd'hui, j'ai trois serveurs qui utilisent chacun une base Berkeley indépendante que j'attaque sous Perl. Je voudrais fusionner ces trois bases qui sont identiques dans la forme mais pas tout à fait dans le contenu car cela dépend aujourd'hui des requêtes sur les serveurs mais en gardant une grande tolérance aux pannes de l'un des serveurs.

Donc en gros, je souhaite avoir trois bases Berkeley qui se synchronise de manière aysnchrone, au mieux... et avoir le moins de code Perl a modifier ;-)

D'ailleurs, je ne comprends pas pourquoi Thunderbird utilise encore le format mbox alors qu'il pourrait utiliser le format Maildir... J'ai eu tout plein d'utilisateurs qui ont eu un thunderbird qui partait en sucette car une boite dépassait les 2Go ! Et Thunderbird ne prévient pas ni ne fait de message explicite alors que le problème existe depuis longtemps...

Ou alors, il garde le format mbox mais le découpe en petit morceaux de 500Mo max...

Au début d'internet, on a pensé que la langue anglaise allait tout dominer et que nous allions tous basculer dessus...

Et puis, internet s'est diversifié, UTF8 s'est mis en place et maintenant les petites langues ont leur place.

Et c'est très bien. Il y a des choses en Breton qui sont infaisable en Français !

s/breizhonneg/brezhoneg/