Sytoka Modon a écrit 4544 commentaires

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

Pour faire des PDF propre de manière automatique, j'utilise en général la chaîne

Perl -> TeX -> PDF.

Perl parce que comme son nom l'indique, ça été conçu pour extraire des données à droite et à gauche et c'est très facile de généré du TeX (LaTeX) avec. TeX parce que c'est le meilleur formateur que je connaisse.

L'informatique c'est bien mais moi j'ai mon carnet de santé de naissance et les docteurs ont écrit plein de truc dessus au cours des ages et c'est bien. Mon carnet a maintenant quelques décennies (non, je ne vous dirais pas mon age !).

Donc, avoir un document TeX quit ferait la trame propre pour avoir un carnet de santé papier, ce serait bien aussi ;-)

Je vois mal un médecin écrire sur ton application ou donner un coup de tampon validant tel ou tel vaccins.

> Tu as oublié de citer ton LUG ...

Express, cela n'a aucune importance pour ce débat.

Je crois que je donnerais plus facilement 100 que 10 fois 10 car je ne suis pas sur d'être capable de suivre en parallèle dix associations.

Et puis, il y a du travail à faire au niveau Européen... Bref, a trop morceler, on finit par ne pas avoir d'action dans la durée. Les actions ponctuelles, c'est bien mais il faut aussi du travail de fond.

Quand à la diversité, on l'a aussi au travers des associations locales.

Cependant, je comprends bien vos points de vue que je partage aussi et je ne suis pas du tout sur que le regroupement serait effectivement une bonne solution.

J'en cite un autre. Tu connais php, pourquoi ne pas basculer sur Perl, des milliers de module... Deux exemples de framework en Perl : Catalyst et Jifty

http://www.catalystframework.org/

http://jifty.org/view/HomePage

> ça apporterait quoi ta proposition de fusion ?

Des finances communes donc cela peut être plus facile de mener des grosses actions. Une gestion commune des adhérents, des AG... L'April a mener une grande campagne pour atteindre les 5000 adhérents. Je ne suis pas sur que cela facile à maintenir et l'énergie mise dans ce genre d'opération doit être dupliquer sur n associations...

Je suis très actif dans une petite association culturelle et à chaque grosse opération, on ne savait pas si on allait tenir financièrement. A chaque fois, c'était risqué. Il y a eu une association du même type qui a eu plusieurs fois des soucis et ils ont fait appel a ces moments la aux dons mais au final, cela lasse. Maintenant, on a le fond de roulement qui nous permet de faire une grosse opération sans tout risquer. On fait donc cela de manière bien plus sereine.

Bref, pour une association, il faut savoir aussi faire des coups d'éclats à la mesure de se que l'on est capable de faire.

Mais tes arguments ne sont pas idiots.

Mais personnellement, je ne vais pas adhérer à l'April, à LQDN, à Aful, à la FSF France... J'ai déjà du mal à suivre le rythme de celle à laquelle j'adhère.

Exactement, je n'avais pas lu ce journal (et par ailleurs, je ne prends pas toujours les commentaires sur linuxfr comme argent comptant).

Merci pour le lien explicatif.

Sinon, ma remarque initiale est toujours valable. Ils pourraient fusionner. Qui dis fusion, dis partage et non forcément dilution et perte. Qu'il y ait des problèmes éventuels de personnes est autre chose.

La question que je me pose c'est pourquoi ne pas fusionner avec l'April ?