Ça existe, c'est pas suffisant. Parce que telnet over ssl, ça existe aussi, pourtant, on préfere ssh.
J'ai pas souvenir avoir vu freenode en ssl, ni undernet, ou quakenet ( 3 gros serveurs que j'ai pris au pif ), par contre, je pense que tout les serveurs jabber le proposent de base.
Quand à l'usage de la commande PASS, pourquoi est ce que personne l'utilise ?
Et il reste aussi le probléme du fait que si je veut aller sur 3 salons sur 3 serveurs différents, ben j'ai 3 comptes différents. Et aussi 3 nicks names, je pense qu'on peut faire mieux en matiére d'auth.
Le probléme, c'est que pour venir sur irc, faut juste un client, pour venir sur un salon jabber, faut un compte jabber. À partir de la, tu as déja un probléme, car il y a pas assez de personnes ayant un compte.
Ensuite, faut reconnaitre, les clients jabber ne sont pas aussi aboutis que les clients jabber. Exemple, pas de script.
Pour ma part, je mise sur le support des salons muc dans bitlbee, mais c'est pas encore dans la version stable ( et j'aimerais bien qu'on merge mes patchs avant la fin des vacances :/ )
La page sur psyc.eu semble oublier divers choses, et ne donne pas de récapitulatif des problémes
1) manque de reliabilité. contrairement à l'expérience de l'auteur, j'ai jamais vu de message perdu. J'ai souvent vu mon serveur tenté de renvoyer les messages, sous la forme de message d'erreur multiple.
2) idle connection. Probléme d'implementation, mais il n'y a pas de lien vers les rapports de bugs si ils existent.
3) roster Asynchronicity, pas de méthodes exacts sur comment reproduire le probléme. Et une fois encore, c'est un probléme d'implémentation.
4) Scalability. Il y a une xep (xep 0133 ) sur le multicast pour ça (et l'intégration en cours dans ejabberd ). Et je suis désolé, c'est pas des pourcentages qu'il faut donner pour savoir si ça monte en charge, mais la bande passante utilisé. Au boulot, on a coupé le cache dns de windows, on a eu une augmentation de 200% du trafic dns interne, clairement vu sur les graphes par un passage de 1k de bande passante à 3k. 200%, ça fait beaucoup, 2k de trafic réseau, ça fait rien en réseau local. Avant de dire que jabber ne scale pas, il faut déja savoir si le probléme vient de la bande passante, de la mémoire, ou d'autres choses.
5) Probléme pour savoir si un noeud est up ou pas. Il y a la xep-0199, pour le ping, qui est relativement trivial à implementer.
6) XML, soit l 'auteur n'aime pas xml. Parce qu'il peut pas transferer des données binaires, parce qu'on peut pas décider de réduire les données à un seul octet ( et tant pis pour l'extensibilité ), parce qu'on peut pas étendre xml facilement, bref, des tas de raisons aussi valides que les commentaires à la fin de la page
7) Xmpp vs Xml, il a pas du lire la rfc qui dit que le protocol sert à streamer des éléments en xml, pas que le flux soit forcement un document valide. Néanmoins, l'auteur ayant la bonne idée de coller des morceaux en allemand, j'ai du sans doute mal comprendre.
8) Having to Guess the Meaning of a Packet, oui, ça s'appelle un protocole extensible. Psyc, permettant la même chose ( à savoir spécialiser les messages ), aura sans doute le même probléme, si un jour il est étendu.
9) MUC the "Multi-User Conference", on passeras sur l'attaque à la con, tout les wikis ne sont pas la pour qu'on pose des questions en toute anarchie, et concentrons nous sur le fait que oui, la forme actuelle des mucs ne permet pas d'avoir 700 personnes dans une chatroom. Soit, et vu l'état actuel, en quoi ça pose probléme, car j'ai jamais vu un salon avec plus de 25 personnes ? Des gens sont conscients du probléme, travaillent dessus ( http://www.xmpp.org/extensions/inbox/distributedmuc.html ), et je pense que ça sera réglé en temps et en heure. Il est connu qu'avec des ressources limités, on peut pas tout faire en même temps.
Le reste est du même tonneau. Bien qu'ayant certaines critiques valides, je pense que la plupart sont noyés sous un style provocant, et sous des manques des initiatives récentes.
Pour en revenir à freenode, irc et les mucs, il faut bien voir que la structure du réseau jabber en forme de federation est bien plus scalable à mon sens que les approches en réseau séparé d'irc, mais peut être que mon intuition est fausse.
Je te conseille à ce moment la d'aller expliquer directement sur leurs forums, tu en trouveras vachement plus, et surtout des gens ouverts à la discussion.
Et donc, au final, au lieu d'attendre que ton patch soit intégré upstream, tu doit attendre que ta branche soit mergé upstream, je me sens vachement plus pris en compte en tant que dev, wooow.
Donc je récapitule : plutot que d'utiliser telepathy, on va
1) mettre en place un serveur xmpp en local
2) mettre en place des passeerelles local pour aller sur les réseaux fermés
3) mettre une passerelle jabber vers jabber pour aller vers le compte jabber principal
Pour le 1, faut que le serveur puisse contacter la passerelle. donc il te faut une ip routable. Ou alors, tu te retrouves à avoir une techno différente de ce qui existe actuellement.
Pour le 2, soit tu passe par le serveur ( ie technologie actuelle des passerelles ), soit tu utilise un truc différent ( et dans ce cas, c'est autant une invantion différente de xmpp que telepathy est actuellement différent )
Pour le 3, la différence avec xmpp, c'est que c'est pris en compte dans la conception de telepathy, alors que jabber est pris de façon indépendante du reste du monde.
Utiliser xmpp pour faire du msn, ça implique de passer par une passerelle, ce qui pose divers problémes :
1) il faut modifier le serveur, ou du moins, avoir un serveur qui fait tourner la passerelle, accesible depuis l'internet. En effet, tout passe par le serveur xmpp, il faut donc avoir un lien entre le serveur et la passerelle. Pas faisable si tu es derriére du nat.
Exemple : je veut parler à quelqu'un avec qq, protocole populaire en chine. Avec empathy/telepathy, j'ai que à rajouter le manager qui va bien, et je peut.
Avec l'approche passerelle, faut que je trouve une passerelle accessible, et si ça existe pas, je ne peut rien faire sur mon pc de simple pour la mettre en place. ( dans les 2 cas, pour le moment, ça n'existe pas )
2) Le passage par le serveur et une passerelle implique d'oublier tout espoir de connexion p2p qui contourne le tout. Par exemple, comment ton client jabber va négocier et utiliser le transfert de fichier avec un client msn sans passerelle ? Et passer par la passerelle serait extrement couteux au niveau réseau dans la plupart des cas. Il ne faut pas oublier que la video passe aussi en direct.
3) tout ne correspond pas directement aux concepts de jabber. par exemple, il suffit de voir les différences entre irc et les salons muc de jabber, notament la gestion du nickname ( 1 par salon sur jabber ), les avatars, les cctp, etc.
Tu as ceci : http://plagger.org/, qui est un framework complet pour lamanipulation rss. À partir d'un fichier de conf, tu peut faire ton planet et le filtrer,etc. Je pense que ça mérite d'être vu.
"Pour cela, Zend veut reprendre les recettes qui ont fait le succès de PHP : des solutions simples et élégantes qui fonctionnent partout."
Comment dire, "qui fonctionnent partout", les gens oublient le merdier des incompatibilités entre version de php, ainsi que les nombreux hacks requis pour adapter les softs à la configuration du serveur ?
Quand aux "solutions simples et élégantes", c'est vrai que le fait de rajouter i à chaque fontion de matching est "élégant" et pas du tout piégeux. Et que la cohérence des fonctions ( avec ou sans _ ), la duplication des fonctions, etc, tout ça le rends "simple" et "élégant", comme le rappelle ce lien http://tnx.nl/php.
Php a des avantages, la facilité ( car visiblement, tout le monde arrive à en faire ), le fait qu'il soit pensé pour offrir un systéme de template web à des users sans avoir à leur donner les droits admins, la capacité de limiter les users au niveau des opérations, etc, mais faut pas non plus essayer de nous faire prendre des vesies pour des lanternes.
J'ai vu avec bonheur le paquet arriver hier soir dans cooker, sur ma mandriva.
Et j'ai testé pour vous, j'ai enfin réussi à compiler et à utiliser openfire avec icedtea. Et en x86_64 ! Depuis le temps que je voulais essayer ce serveur. Seul bémol, j'ai pas réussi à activer les fonctionnalités ssl, mais je pense qu'il manque simplement une lib.
Il y a aussi swfdec ( http://swfdec.freedesktop.org/wiki/ ), qui est en quelque mois devenu un concurent sérieux de gnash au niveau du plugin. Le projet est bien plus modeste que gnash au niveau des objectifs, mais semble avancer trés vite.
Par exemple, le support de youtube a été codé en quelque mois, et le codeur principal est en train de refondre completement le moteur de scripting pour supporter bien plus de choses.
Surtout qu'il y a quand même trés largement le choix des projets ou contribuer, il y en a pour tout les gouts. Du python ( gajim ), du c++ ( psi, gossip ), du tcl ( tkabber ), du java ( openfire, spark ), du C ( bitlbee, telepathy, pidgin, jabberd ), du perl ( djabberd ), de l'erlang ( ejabberd ).
Tout le monde fait peut être de l'assembleur ou de l'haskell et ne trouve pas chaussure à son pied ?
De plus, avoir un standard ouvert et documenté, c'est vachement plus simple à implementer que de devoir sniffer des structures binaires, de devoir gérer des versions et de devoir tester sans savoir exactement ce que l'implémentation de reference fait, car c'est un binaire proprio qui fait transité tout par un serveur distant.
Et du travail pour les débutants, il y en a des tonnes. Des trucs simples à rajouter, il y a le support de ping ( xep-0199 ), celui de last:time ( xep-0012 ), ou simplement divers morceaux manquants des grosses extensions ( notament pour les multi users chats, ou je pense qu'il manque des trucs genre request voice ). Ou la vérification du standard.
Ou plus simplement, prendre les clients en version de dev, et faire des bugs reports ( et des patchs aussi , ç'est en général assez rapide ).
J'ai donc pas l'impression que le probléme soit la difficulté de contribuer. Ni même le temps, ça demande pas des investissements énorme à ce niveau la pour les taches simples ( genre le wiki de jabberfr ).
Il y a simplement un manque d'intêret à ce niveau la, les gens n'utilisent pas jabber, ou ceux qui l'utilisent donnent peut être avant tout leur msn sans savoir que leur contact a aussi jabber. Au bout d'un moment, ils arrêtent d'utiliser leur compte jabber car ils ont pas de contact, et voila.
Même avec toutes les features du monde, les gens utiliseront pas jabber tant qu'il y aura pas du monde dessus.
Pour ça, on pourrait imaginer que les fournisseurs se mettent à offrir un compte jabber avec la messagerie, avec le même login/mot de passe. Grosso modo ce que fait google. Mais j'ai du mal à voir la valeur ajouté pour eux.
On peut imaginer une entrée en douce via le monde de l'entreprise, ou il y a plus de chances de trouver des personnes pour monter un serveur. Même si j'ai des doutes à ce niveau la.
Et sinon, on peut imaginer une killer feature avec jabber, comme l'édition musical partagé avec jokosher( http://blog.mikeasoft.com/2007/06/18/jokosher-network-instru(...) ), ou inkskape. À ce niveau la, il y des discussions autour de gnome ( http://guadec.org/node/521 ), et je pense que telepathy va permettre d'aller plus loin.
Le seul bemol, c'est que telepathy marche aussi avec msnp, donc je ne sais pas si ça va forcément aider xmpp.
Mais si tu implémente un logiciel proprio sous forme libre, est ce que tu ne libéres pas les gens ?
Regarde swfdec, l'autre alternative à flash ( qui, soit dit en passant, fait tourner youtube aussi et ceci quelque jour avant gnash, alors que l'équipe sur swfdec est bien plus réduirte ), qui permet d'une part de debuguer les fichiers flash, mais aussi de les bloquer sans extensions ( pour konqueror , par exemple ), mais également de récuperer les différents urls et morceaux du .swf, ce qui permet par exemple de facilmeent sauvegardé les videos youtube.
Un logiciel libre, par sa portabilité, libère aussi l'utilisateur d'une techno proprio, car tu ne dépend plus de l'éditeur. C'est donc pas forcément si mal.
C'est un peu facile de dire que c'est la faute des distros, mais il faut bien voir que les patchs, c'est aussi pour des bugfixes, souvent trouvé par le dev, ou les users, et parfois avant la sortie de la distro.
Tu te voit dire "oui, on a trouvé le probléme à temps, mais on attends que XXX sorte le logiciel, et si XXX mets du temps, ben tant pis pour vous. et si jamais il a aussi rajouter des tonnes de trucs non testés et incompatible, c'est pas grave, on va mettre à jour aussi 2h avant la final"
Les patchs servent aussi pour les incompatibilités. Tu va encore une fois pas attendre que le dev installe une nouvelle version d'une lib si il veut pas ou n'a pas le temps, et une fois encore, attendre une nouvelle release fait perdre du temps. Si au lieu d'avoir un paquet prés à tester, tu attends une semaine ( cas trés favorable d'un upstream qui sort le tarball tout de suite ), ben tu as pris du retard.
Enfin, il y a des patchs pour les fonctionnalités. Et c'est demandé par qui, les nouvelles fonctionnaltiés ? Par les utilisateurs, qui au final font pression indirectement sur les distributions.
Il y a au final bien plus de patchs utiles et valides que de patchs qui posent probléme. Et les patchs sont souvent remontés upstream, quand il existe et qu'il les accepte.
/tmp/test_debian $ ar x 6tunnel_0.11rc2-2_s390.deb
/tmp/test_debian $ ls
6tunnel_0.11rc2-2_s390.deb control.tar.gz data.tar.gz debian-binary
/tmp/test_debian $ tar -tzf control.tar.gz
./
./md5sums
./control
/tmp/test_debian $ tar -xzf control.tar.gz ; cat ./control
Package: 6tunnel
Version: 0.11rc2-2
Section: net
Priority: optional
Architecture: s390
Depends: libc6 (>= 2.3.5-1)
Installed-Size: 68
Maintainer: Thomas Seyrat <tomasera@debian.org>
Description: TCP proxy for non-IPv6 applications
6tunnel allows you to use services provided by IPv6 hosts with
IPv4-only applications and vice versa. It can bind to any of your IPv4
or IPv6 addresses and forward all data to IPv4 or IPv6 host.
.
It can be used for example as an IPv6-capable IRC proxy.
/tmp/test_debian $
Alors le "ça fonctionne", je me permet de remettre ça en doute.
Le jour ou on eu besoin du paquet, pour mettre un chroot rpm sur une debian, ça s'est fini par une compilation à la main tellement la version dans woody/sarge était en retard.
Mais heuresement, ç'est plus le cas dans etch, la version de rpm est la 4.4.1 ( sachant que la 4.4.8 vient de sortir ou va sortir, et que la 4.4.1 date de décembre 2004.
Pour l'usage que font les debianneux de rpm, je pense que ça suffit.
En l'occurence c'est un paquet de contribs donc non officiel et non supporté, et la blague ( car, oui, c'est juste une blague, je voit pas comment ça pourrait être autre chose ) est la depuis les rmll 2003, si je me souvient bien.
Dans la mesure ou les .deb ne sont que des archives ar qu'on peut ouvrir avec ar x, utiliser dpkg reléve de l'usine à gaz pour l'usage qu'on peut en faire sur Mandriva càd rien, car je rappelle que c'est pas l'archive mais le contenu qui est important.
[^] # Re: ou alors...
Posté par Misc (site web personnel) . En réponse au journal IRC Plus, une initiative pour harmoniser les services IRC. Évalué à 6.
J'ai pas souvenir avoir vu freenode en ssl, ni undernet, ou quakenet ( 3 gros serveurs que j'ai pris au pif ), par contre, je pense que tout les serveurs jabber le proposent de base.
Quand à l'usage de la commande PASS, pourquoi est ce que personne l'utilise ?
Et il reste aussi le probléme du fait que si je veut aller sur 3 salons sur 3 serveurs différents, ben j'ai 3 comptes différents. Et aussi 3 nicks names, je pense qu'on peut faire mieux en matiére d'auth.
[^] # Re: ou alors...
Posté par Misc (site web personnel) . En réponse au journal IRC Plus, une initiative pour harmoniser les services IRC. Évalué à 3.
Alors oui, en se basant sur irc, on peut faire un truc en dehors du standard, mais userfriendly.
[^] # Re: ou alors...
Posté par Misc (site web personnel) . En réponse au journal IRC Plus, une initiative pour harmoniser les services IRC. Évalué à 4.
[^] # Re: ou alors...
Posté par Misc (site web personnel) . En réponse au journal IRC Plus, une initiative pour harmoniser les services IRC. Évalué à 3.
Ensuite, faut reconnaitre, les clients jabber ne sont pas aussi aboutis que les clients jabber. Exemple, pas de script.
Pour ma part, je mise sur le support des salons muc dans bitlbee, mais c'est pas encore dans la version stable ( et j'aimerais bien qu'on merge mes patchs avant la fin des vacances :/ )
[^] # Re: ou alors...
Posté par Misc (site web personnel) . En réponse au journal IRC Plus, une initiative pour harmoniser les services IRC. Évalué à 4.
1) manque de reliabilité. contrairement à l'expérience de l'auteur, j'ai jamais vu de message perdu. J'ai souvent vu mon serveur tenté de renvoyer les messages, sous la forme de message d'erreur multiple.
2) idle connection. Probléme d'implementation, mais il n'y a pas de lien vers les rapports de bugs si ils existent.
3) roster Asynchronicity, pas de méthodes exacts sur comment reproduire le probléme. Et une fois encore, c'est un probléme d'implémentation.
4) Scalability. Il y a une xep (xep 0133 ) sur le multicast pour ça (et l'intégration en cours dans ejabberd ). Et je suis désolé, c'est pas des pourcentages qu'il faut donner pour savoir si ça monte en charge, mais la bande passante utilisé. Au boulot, on a coupé le cache dns de windows, on a eu une augmentation de 200% du trafic dns interne, clairement vu sur les graphes par un passage de 1k de bande passante à 3k. 200%, ça fait beaucoup, 2k de trafic réseau, ça fait rien en réseau local. Avant de dire que jabber ne scale pas, il faut déja savoir si le probléme vient de la bande passante, de la mémoire, ou d'autres choses.
5) Probléme pour savoir si un noeud est up ou pas. Il y a la xep-0199, pour le ping, qui est relativement trivial à implementer.
6) XML, soit l 'auteur n'aime pas xml. Parce qu'il peut pas transferer des données binaires, parce qu'on peut pas décider de réduire les données à un seul octet ( et tant pis pour l'extensibilité ), parce qu'on peut pas étendre xml facilement, bref, des tas de raisons aussi valides que les commentaires à la fin de la page
7) Xmpp vs Xml, il a pas du lire la rfc qui dit que le protocol sert à streamer des éléments en xml, pas que le flux soit forcement un document valide. Néanmoins, l'auteur ayant la bonne idée de coller des morceaux en allemand, j'ai du sans doute mal comprendre.
8) Having to Guess the Meaning of a Packet, oui, ça s'appelle un protocole extensible. Psyc, permettant la même chose ( à savoir spécialiser les messages ), aura sans doute le même probléme, si un jour il est étendu.
9) MUC the "Multi-User Conference", on passeras sur l'attaque à la con, tout les wikis ne sont pas la pour qu'on pose des questions en toute anarchie, et concentrons nous sur le fait que oui, la forme actuelle des mucs ne permet pas d'avoir 700 personnes dans une chatroom. Soit, et vu l'état actuel, en quoi ça pose probléme, car j'ai jamais vu un salon avec plus de 25 personnes ? Des gens sont conscients du probléme, travaillent dessus ( http://www.xmpp.org/extensions/inbox/distributedmuc.html ), et je pense que ça sera réglé en temps et en heure. Il est connu qu'avec des ressources limités, on peut pas tout faire en même temps.
Le reste est du même tonneau. Bien qu'ayant certaines critiques valides, je pense que la plupart sont noyés sous un style provocant, et sous des manques des initiatives récentes.
Pour en revenir à freenode, irc et les mucs, il faut bien voir que la structure du réseau jabber en forme de federation est bien plus scalable à mon sens que les approches en réseau séparé d'irc, mais peut être que mon intuition est fausse.
[^] # Re: J'ai remplacé ubuntu par debian
Posté par Misc (site web personnel) . En réponse au journal Retour vers le futur pour MEPIS. Évalué à 3.
Il y a surement des topics prévus pour.
[^] # Re: Acces CVS
Posté par Misc (site web personnel) . En réponse au journal Retours d'expérience sur contributions au libre. Évalué à 4.
[^] # Re: XMPP / Empathy
Posté par Misc (site web personnel) . En réponse à la dépêche Empathy : l'avenir de la messagerie instantanée dans GNOME. Évalué à 4.
1) mettre en place un serveur xmpp en local
2) mettre en place des passeerelles local pour aller sur les réseaux fermés
3) mettre une passerelle jabber vers jabber pour aller vers le compte jabber principal
[^] # Re: XMPP / Empathy
Posté par Misc (site web personnel) . En réponse à la dépêche Empathy : l'avenir de la messagerie instantanée dans GNOME. Évalué à 5.
Pour le 2, soit tu passe par le serveur ( ie technologie actuelle des passerelles ), soit tu utilise un truc différent ( et dans ce cas, c'est autant une invantion différente de xmpp que telepathy est actuellement différent )
Pour le 3, la différence avec xmpp, c'est que c'est pris en compte dans la conception de telepathy, alors que jabber est pris de façon indépendante du reste du monde.
[^] # Re: XMPP / Empathy
Posté par Misc (site web personnel) . En réponse à la dépêche Empathy : l'avenir de la messagerie instantanée dans GNOME. Évalué à 5.
1) il faut modifier le serveur, ou du moins, avoir un serveur qui fait tourner la passerelle, accesible depuis l'internet. En effet, tout passe par le serveur xmpp, il faut donc avoir un lien entre le serveur et la passerelle. Pas faisable si tu es derriére du nat.
Exemple : je veut parler à quelqu'un avec qq, protocole populaire en chine. Avec empathy/telepathy, j'ai que à rajouter le manager qui va bien, et je peut.
Avec l'approche passerelle, faut que je trouve une passerelle accessible, et si ça existe pas, je ne peut rien faire sur mon pc de simple pour la mettre en place. ( dans les 2 cas, pour le moment, ça n'existe pas )
2) Le passage par le serveur et une passerelle implique d'oublier tout espoir de connexion p2p qui contourne le tout. Par exemple, comment ton client jabber va négocier et utiliser le transfert de fichier avec un client msn sans passerelle ? Et passer par la passerelle serait extrement couteux au niveau réseau dans la plupart des cas. Il ne faut pas oublier que la video passe aussi en direct.
3) tout ne correspond pas directement aux concepts de jabber. par exemple, il suffit de voir les différences entre irc et les salons muc de jabber, notament la gestion du nickname ( 1 par salon sur jabber ), les avatars, les cctp, etc.
# Et ç'est déja utilisé
Posté par Misc (site web personnel) . En réponse à la dépêche Empathy : l'avenir de la messagerie instantanée dans GNOME. Évalué à 5.
- Soylent ( http://live.gnome.org/Soylent ), cf http://treitter.livejournal.com/1604.html. Soylent est un gestionnaire de personnes, un peu comme nautilus pour le carnet d'addresse.
- un plugin pour epiphany ( http://blog.senko.net/2007/07/19/emphatic-epiphany/ ), pour envoyer un lien directement à un client
- Jokosher, ou on pourras à terme faire des interviews de gens avec la de la voip , via le réseau ( http://blog.mikeasoft.com/2007/05/07/jokosher-soc/ )
Et je suis sur qu'il y a des tas d'idées à implementer ( file sharing sur le reseau via telepathy-salut, etc , etc ).
# et du coté de perl..
Posté par Misc (site web personnel) . En réponse au journal Créer un "Planet". Évalué à 3.
# *khof* *khof*
Posté par Misc (site web personnel) . En réponse à la dépêche Zend Framework 1.0.0 : PHP à la suite de Ruby on Rail. Évalué à 4.
Comment dire, "qui fonctionnent partout", les gens oublient le merdier des incompatibilités entre version de php, ainsi que les nombreux hacks requis pour adapter les softs à la configuration du serveur ?
Quand aux "solutions simples et élégantes", c'est vrai que le fait de rajouter i à chaque fontion de matching est "élégant" et pas du tout piégeux. Et que la cohérence des fonctions ( avec ou sans _ ), la duplication des fonctions, etc, tout ça le rends "simple" et "élégant", comme le rappelle ce lien http://tnx.nl/php.
Php a des avantages, la facilité ( car visiblement, tout le monde arrive à en faire ), le fait qu'il soit pensé pour offrir un systéme de template web à des users sans avoir à leur donner les droits admins, la capacité de limiter les users au niveau des opérations, etc, mais faut pas non plus essayer de nous faire prendre des vesies pour des lanternes.
# Aprés test
Posté par Misc (site web personnel) . En réponse au journal Java libre: le projet IcedTea. Évalué à 3.
Et j'ai testé pour vous, j'ai enfin réussi à compiler et à utiliser openfire avec icedtea. Et en x86_64 ! Depuis le temps que je voulais essayer ce serveur. Seul bémol, j'ai pas réussi à activer les fonctionnalités ssl, mais je pense qu'il manque simplement une lib.
Avoir java enfin libre est une bonne nouvelle.
# y a pas que gnash
Posté par Misc (site web personnel) . En réponse au journal Quels outils pour remplacer Flash(c)(tm)(100%cpu) ?. Évalué à 6.
Par exemple, le support de youtube a été codé en quelque mois, et le codeur principal est en train de refondre completement le moteur de scripting pour supporter bien plus de choses.
[^] # Re: hum
Posté par Misc (site web personnel) . En réponse au journal Support du protocole MSNP.... Évalué à 4.
Surtout qu'il y a quand même trés largement le choix des projets ou contribuer, il y en a pour tout les gouts. Du python ( gajim ), du c++ ( psi, gossip ), du tcl ( tkabber ), du java ( openfire, spark ), du C ( bitlbee, telepathy, pidgin, jabberd ), du perl ( djabberd ), de l'erlang ( ejabberd ).
Tout le monde fait peut être de l'assembleur ou de l'haskell et ne trouve pas chaussure à son pied ?
De plus, avoir un standard ouvert et documenté, c'est vachement plus simple à implementer que de devoir sniffer des structures binaires, de devoir gérer des versions et de devoir tester sans savoir exactement ce que l'implémentation de reference fait, car c'est un binaire proprio qui fait transité tout par un serveur distant.
Et du travail pour les débutants, il y en a des tonnes. Des trucs simples à rajouter, il y a le support de ping ( xep-0199 ), celui de last:time ( xep-0012 ), ou simplement divers morceaux manquants des grosses extensions ( notament pour les multi users chats, ou je pense qu'il manque des trucs genre request voice ). Ou la vérification du standard.
Ou plus simplement, prendre les clients en version de dev, et faire des bugs reports ( et des patchs aussi , ç'est en général assez rapide ).
J'ai donc pas l'impression que le probléme soit la difficulté de contribuer. Ni même le temps, ça demande pas des investissements énorme à ce niveau la pour les taches simples ( genre le wiki de jabberfr ).
Il y a simplement un manque d'intêret à ce niveau la, les gens n'utilisent pas jabber, ou ceux qui l'utilisent donnent peut être avant tout leur msn sans savoir que leur contact a aussi jabber. Au bout d'un moment, ils arrêtent d'utiliser leur compte jabber car ils ont pas de contact, et voila.
[^] # Re: Et pourquoi...
Posté par Misc (site web personnel) . En réponse au journal Support du protocole MSNP.... Évalué à 3.
Pour ça, on pourrait imaginer que les fournisseurs se mettent à offrir un compte jabber avec la messagerie, avec le même login/mot de passe. Grosso modo ce que fait google. Mais j'ai du mal à voir la valeur ajouté pour eux.
On peut imaginer une entrée en douce via le monde de l'entreprise, ou il y a plus de chances de trouver des personnes pour monter un serveur. Même si j'ai des doutes à ce niveau la.
Et sinon, on peut imaginer une killer feature avec jabber, comme l'édition musical partagé avec jokosher( http://blog.mikeasoft.com/2007/06/18/jokosher-network-instru(...) ), ou inkskape. À ce niveau la, il y des discussions autour de gnome ( http://guadec.org/node/521 ), et je pense que telepathy va permettre d'aller plus loin.
Le seul bemol, c'est que telepathy marche aussi avec msnp, donc je ne sais pas si ça va forcément aider xmpp.
[^] # Re: Attristant...
Posté par Misc (site web personnel) . En réponse au journal Silverlight sous linux : moonlight. Évalué à 7.
Regarde swfdec, l'autre alternative à flash ( qui, soit dit en passant, fait tourner youtube aussi et ceci quelque jour avant gnash, alors que l'équipe sur swfdec est bien plus réduirte ), qui permet d'une part de debuguer les fichiers flash, mais aussi de les bloquer sans extensions ( pour konqueror , par exemple ), mais également de récuperer les différents urls et morceaux du .swf, ce qui permet par exemple de facilmeent sauvegardé les videos youtube.
Un logiciel libre, par sa portabilité, libère aussi l'utilisateur d'une techno proprio, car tu ne dépend plus de l'éditeur. C'est donc pas forcément si mal.
[^] # Re: Désolé, cela ne me fait pas rire
Posté par Misc (site web personnel) . En réponse au journal MWAHAHAHAHAHA !. Évalué à 5.
Tout comme il est évident qu'un employé en dehors du bureau ne bosse pas, et ce genre de choses.
[^] # Re: C'est quoi ....
Posté par Misc (site web personnel) . En réponse au journal Lutèces d'Or, les résultats. Évalué à 2.
"- Lutèce de la personnalité de l'année 2007 : L'Assemblée nationale"
ça a fini par se voir ?
[^] # Re: on y est déja sorti en fait...
Posté par Misc (site web personnel) . En réponse au journal Le retour de RPM - Divergences sur la convergence. Évalué à 2.
Tu te voit dire "oui, on a trouvé le probléme à temps, mais on attends que XXX sorte le logiciel, et si XXX mets du temps, ben tant pis pour vous. et si jamais il a aussi rajouter des tonnes de trucs non testés et incompatible, c'est pas grave, on va mettre à jour aussi 2h avant la final"
Les patchs servent aussi pour les incompatibilités. Tu va encore une fois pas attendre que le dev installe une nouvelle version d'une lib si il veut pas ou n'a pas le temps, et une fois encore, attendre une nouvelle release fait perdre du temps. Si au lieu d'avoir un paquet prés à tester, tu attends une semaine ( cas trés favorable d'un upstream qui sort le tarball tout de suite ), ben tu as pris du retard.
Enfin, il y a des patchs pour les fonctionnalités. Et c'est demandé par qui, les nouvelles fonctionnaltiés ? Par les utilisateurs, qui au final font pression indirectement sur les distributions.
Il y a au final bien plus de patchs utiles et valides que de patchs qui posent probléme. Et les patchs sont souvent remontés upstream, quand il existe et qu'il les accepte.
[^] # Re: ...
Posté par Misc (site web personnel) . En réponse au journal Mandriva et dpkg. Évalué à 2.
~ $ mkdir /tmp/test_debian
~ $ cd /tmp/test_debian
/tmp/test_debian $ wget ftp.fr.debian.org/debian/pool/main/6/6tunnel/6tunnel_0.11rc2-2_s390.deb
--00:12:57-- http://ftp.fr.debian.org/debian/pool/main/6/6tunnel/6tunnel_(...)
=> `6tunnel_0.11rc2-2_s390.deb'
Résolution de ftp.fr.debian.org... 212.27.32.66
Connexion vers ftp.fr.debian.org|212.27.32.66|:80...connecté.
requête HTTP transmise, en attente de la réponse...200 OK
Longueur: 11,698 (11K) [application/x-debian-package]
100%[====================================>] 11,698 --.--K/s
00:12:57 (172.36 KB/s) - « 6tunnel_0.11rc2-2_s390.deb » sauvegardé [11698/11698]
/tmp/test_debian $ ar x 6tunnel_0.11rc2-2_s390.deb
/tmp/test_debian $ ls
6tunnel_0.11rc2-2_s390.deb control.tar.gz data.tar.gz debian-binary
/tmp/test_debian $ tar -tzf control.tar.gz
./
./md5sums
./control
/tmp/test_debian $ tar -xzf control.tar.gz ; cat ./control
Package: 6tunnel
Version: 0.11rc2-2
Section: net
Priority: optional
Architecture: s390
Depends: libc6 (>= 2.3.5-1)
Installed-Size: 68
Maintainer: Thomas Seyrat <tomasera@debian.org>
Description: TCP proxy for non-IPv6 applications
6tunnel allows you to use services provided by IPv6 hosts with
IPv4-only applications and vice versa. It can bind to any of your IPv4
or IPv6 addresses and forward all data to IPv4 or IPv6 host.
.
It can be used for example as an IPv6-capable IRC proxy.
/tmp/test_debian $
Ou il y a des metadonnées qui manquent ?
[^] # Re: Ha ?
Posté par Misc (site web personnel) . En réponse au journal Mandriva et dpkg. Évalué à 2.
Le jour ou on eu besoin du paquet, pour mettre un chroot rpm sur une debian, ça s'est fini par une compilation à la main tellement la version dans woody/sarge était en retard.
Mais heuresement, ç'est plus le cas dans etch, la version de rpm est la 4.4.1 ( sachant que la 4.4.8 vient de sortir ou va sortir, et que la 4.4.1 date de décembre 2004.
Pour l'usage que font les debianneux de rpm, je pense que ça suffit.
[^] # Re: ...
Posté par Misc (site web personnel) . En réponse au journal Mandriva et dpkg. Évalué à 1.
Et alien est une aberation.
[^] # Re: ...
Posté par Misc (site web personnel) . En réponse au journal Mandriva et dpkg. Évalué à 2.
Dans la mesure ou les .deb ne sont que des archives ar qu'on peut ouvrir avec ar x, utiliser dpkg reléve de l'usine à gaz pour l'usage qu'on peut en faire sur Mandriva càd rien, car je rappelle que c'est pas l'archive mais le contenu qui est important.