Sytoka Modon a écrit 4551 commentaires

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...

Aujourd'hui, le Flash encapsule du H264... donc le H264 est déjà la et le flash, c'est aussi du H264 !

Ensuite, dire que le H264 n'est pas fait pour le stream, je trouve cela un peu fort. Le H264 a été fait pour le visio, par la visio et donc pour le temps réel (d'ou son appellation commençant par H). La visio, cela fait partis du stream...

Pas de soucis, avec CouchDB, on aura bientôt nos propres nuages et Google peut aussi perdre rapidement ses avantages...

Par exemple, dans ma boite, on va bientôt avoir une solution de type skype+vidéo de qualité (H264 + H239) en interne (mais propriétaire) qui vont permettent de nous débarrasser de Skype et tous ces trucs peu claire qui traînent sur la toile. Je vais monter en parallèle mon propre serveur jabber.

C'est aussi une tendance d'avoir tout un tas de service en interne, même s'ils sont propriétaires.

Je suis assez d'accord. Les outils de visio et les télés passent globalement tous par le H264. C'est une tendance lourde et pour le renverser, il faut un codec de meilleure qualité. On ne change pas un codec en visio pour aller vers un codec moins bien !

A l'époque du problème du GIF, le PNG n'avait pas percé alors qu'il était de meilleure qualité que le GIF ! Imaginez que le PNG soit de moins bonne qualité, il aurait complètement disparus de nos jours !

Netscape n'a pas bloqué le GIF, si Mozilla n'implante pas le H264, ses pars de marchés vont s'effondrer très vite. Il ne faut pas sur-estimer la force de Mozilla.

Mozilla peut très bien implanter un système de type plugin et mettre un logo sur les vidéo H264 pour forcer un action de l'utilisateur avant de lancer la vidéo. Un peu comme fait FlashBlock. D'ailleurs, personnellement, je préférerais cela histoire que toutes les vidéos ne se lancent pas en automatique sachant que le décodage vidéo est bien plus compliqué que la lecture d'une image et que les implémentations doivent être trouées de partout.

Les H se suivent mais ne se ressemblent pas toujours ;-)

Enfin, d'ici 2016, il y aura peut être aussi un successeur a H264, ou alors, cela sera encore le H264 mais qui n'aura plus grand chose a voir avec celui d'aujourd'hui.

> Je ne suis pas d'accord avec "le flop annoncé".

Cependant, tu ne vas pas l'acheter...

Je pense qu'il y a une place pour ces gadgets effectivement mais à base de noyau Linux, c'est beaucoup plus souple et la concurrence va jouer à fond. Apple sera donc trop chère pour une plus value pas évidente à par le logo (et j'en connais qui sont près à mettre beaucoup dans celui-ci à chaque fois).

Apple arrive aussi de se planter -> Newton.

Personnellement, je ne crois pas à cette machine mais si cela marche, tant mieux pour Apple.

Il y a un module Perl qui permet de faire ce genre de chose facilement.

http://search.cpan.org/~dlux/Parallel-ForkManager-0.7.5/Fork(...)

Sur debian, cela revient à faire

apt-get install libparallel-forkmanager-perl

L'avantage est que ce n'est pas une usine à gaz. Un seul fichier .pm et Perl sur le poste et ça roule... Bref, c'est basique mais marche partout. A une époque, j'avais copié le .pm dans mon projet comme cela, mon programme marchait sur tous les postes GNU/Linux.

Il y a d'autres modules du même genre mais je ne les ai jamais essayé. Chercher sur le CPAN avec "Parallel Fork"

Il faut aussi une politique pour migrer les données d'un site vers le nouveau... Je viens de faire le passage d'un spip à un autre et c'est déjà un boulot énorme pour tout retrouver pareil puis maintenant mettre les nouvelles fonctionnalité.

Un site comme debian, il faut le migrer d'un coup car si tu bidouilles ensuite pendant 15 jours, c'est terrible comme contre pub pour le projet. Donc c'est un énorme boulot à préparer...

Il pourrait à mon avis faire cela en douceur, et c'est ce qu'il me semble qui se passe. Ils ont déjà virer les TABLE et mis des DIV un peu partout. L'étape d'après est de modifier le CSS pour changer l'aspect. L'étape finale consistant à modifier la structure des rubriques !

Pour le backup, rien ne vaut une ligne de commande, on fera toujours la même chose... Pour un disque externe en fat, je fais un truc du genre

rsync -rvt --modify-window=1 /home/moi/dossier_sav/ /backup/moi/dossier_sav/

On peut même mettre --delete pour virer les anciens fichiers dans le backup les fois suivantes...