Sytoka Modon a écrit 4586 commentaires

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.

A quand un autre spaghetti pour installer et gérer JASMINe ;-)

Il faut que tu te relises à tête reposé car ce que tu racontes n'as ni queue ni tête ;-)

Je n'en extrait qu'une seule phrase : << en visio tu n'es pas en direct >>

On ne parle pas de la même visio... Celle dont je parle, ce sont les terminaux Polycom, Tandberg, les ponts MGC, Codian... C'est de la visio multi-site temps réel avec deux flux vidéo (H239) et justement, il n'y a pas tant que cela de système d'enregistrement capable de prendre les trois flux et d'avoir ensuite des outils de CUT qui te permette de virer des séquences et de rester synchro.

Je ne sais pas ce que tu appelles programmes de streaming, est-ce le client ou le serveur ?

Bref, je dois avouer que je n'ai pas compris ou tu voulais en venir.

A ma connaissance, c'est pwm qui a introduit le système à onglet. Je suis bien content que cela arrive enfin sur les bureaux grands publics.

Pour moi, le stream, c'est du temps réel comme en visio. Il n'y a pas téléchargement. En visio, tu ne télécharges pas !

Pour que cela marche, il faut un codec << temps réel >> donc que le client est le plus petit tampon possible. Si des paquets sont perdus, il doit sauter des frames vidéo mais pas audio car l'audio est toujours (presque) le plus important et l'oreille est bien plus sensible a un saut.

Dans le stream "web", il peux y avoir une fonctionnalité de plus qui consiste à dire au serveur : j'avance a telle frame, et hop le serveur te diffuse à partir de cette frame.

Ta définition du stream n'est que du cache local, pour moi, c'est pas du vrai stream. Que ton logiciel fasse une copie en temps réel sur le disque, pourquoi pas, c'est un plus mais ce n'est pas obligatoire. En visio, on appelle cela enregistrer la session. Dis moi comment-fais tu avec ta solution de stream pour visionner un film de 5 h ?

Pour moi, le stream video, c'est comme écoute une web-radio en pratique sauf qu'il y a le canal vidéo. Bref, c'est la télé en ligne. Lorsque j'écoute france-inter sur le web, au bout d'une heure, il n'y a rien de plus sur mon disque dur qu'une heure avant. C'est pas comme avec youtube et autres sites ou ton disque dur déborde de vidéo à la fin (ce qui peut peut être pratique pour en garder une copie locale) et ou ton navigateur nettoie ton cache...