Sytoka Modon a écrit 4565 commentaires

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/

A terme, on peut imaginer que les PC (portable) ait aussi un accès GSM, 3G... Alors là, avoir une pile libre devient encore plus évident !

J'avais programmé un truc en perl a une époque qui imposait aussi d'avoir un symbole. Je n'ai pas vu cela dans votre programme. Il serait intéressant d'avoir cela à mon avis, obliger les personnes a avoir un symbole parmi une liste de symbole possible (il y en a qui était gênant dans certaines applications donc je les avais éliminer.

Mon programme vérifiait la contrainte sur les 8 premiers caractères mais le mot de passe pouvait en comporter 12, 16 ou plus... Je ne vois pas l'intérêt de limiter la taille maximale du mot de passe par contre, ce qui est intéressant est de forcer la contrainte sur un certain nombre maximum de caractères. C'était surtout très important avec les anciens hash sous Windows qui coupait à deux fois 8.

Ma règle à l'époque était donc la suivante :

- au moins 6 octets

- au moins 1 grande lettre parmi les 8 premiers octets
- au moins 1 petite lettre parmi les 8 premiers octets
- au moins 1 chiffre parmi les 8 premiers octets
- au moins 1 symbole parmi les 8 premiers octets

- pas dans un dico via un recherche rapide (cracklib)

Avec cela, john crackait très peu de mot de passe et mes utilisateurs étaient obligé d'utiliser autre chose que ce qu'il mettait partout (gmail, facebook...).

Si mes souvenirs sont bon et pour simplifier à coup de hache : openoffice = sun => assez fermé. go-ooo est une branche bien plus communautaire ou il y a un peu toutes les distrib linux dessus : Suse, debian...

Bref, go-ooo est un peu l'adaptation d'openoffice aux distrib linux avec on va dire un certain de patch en plus.

Si tu veux une API riche, libre et extensible, va voir sur le CPAN de Perl ;-)

Moi, les packages en org.machin.truc... je pense que le défaut de conception est à la racine.