Luc Stepniewski a écrit 28 commentaires

Dis, tu n'as pas vraiment lu ce que j'avais écris ? J'ai bien dit que Gnomemeeting était plus orienté H323 que SIP bien qu'il le supporte, mais pas de façon "prioritaire".

Pareil pour "le seul" concurrent libre, j'ai donné plusieurs références. Je te les redonne avec les url vu que tu n'as pas l'air d'avoir lu mon message jusqu'au bout:

- Kphone (k pour KDE): http://www.wirlab.net/kphone/
- Minisip: http://www.minisip.org/ (personnellement mon préféré. simple fait juste ce que je veux: appeler/répondre).
- Twinkle (http://www.twinklephone.com/ )
- Shtoom (http://shtoom.divmod.org/ ): en python + twisted !
- linphone (http://www.linphone.org )
- sipXphone and sipXezPhone (http://www.sipfoundry.org/sipXphone/ )

Ils sont TOUS Opensource. Ca fait pas mal de concurrents, non? Il y en a d'autres. Tu pourras trouver une liste non exhaustive sur http://www.voip-info.org/wiki-Open+Source+VOIP+software .

OpenWengo n'est qu'un exemple. Il y a des dizaines de logiciels, tous basés sur un protocole standardisé, publié et libre qui s'appelle SIP. Pour n'en citer que quelques uns: GnomeMeeting (bien qu'il soit plus orienté H323), kphone, minisip, etc. (une liste assez complète se trouve sur http://www.voip-info.org/wiki/index.php?page=VOIP+Phones ).

Personnellement, je me suis intéressé à la VoIP il n'y a que très peu de temps de cela, et je me rend compte que c'est assez similaire au monde Microsoft/Linux. D'un coté tu as quelques logiciels totalement propiétaires, implémentant des protocoles horribles, fermés, buggés, non portables et accompagnés d'EULA à tomber par terre (Skype pour n'en citer que le plus connu qui autorise à utiliser ta machine pour faire du calcul), et de l'autre côté, si tu fais un miminum de recherches, un monde très proche du libre, voire libre où tu peux téléphoner pour quasiment rien n'importe où dans le monde (et en utilisant des logiciels libres).
Par exemple, faites une recherche sur 'FWD' sur Google, et vous trouverez le plus gros opérateur (FreeWorldDialup, http://www.freeworlddialup.com/ ) supportant SIP. Concernant les passerelles entrantes téléphone physique->réseau SIP, on peut en trouver des gratuites assez facilement, voire même des opérateurs qui permettent le financement réseau SIP->téléphone fixe avec l'argent récupéré sur les gens qui te téléphonent (http://www.voipuser.org/ pour le + connu). Un très bon site pour tout savoir sur les opérateurs, les logiciels, les bon plans, les numéros est http://www.voip-info.org/ ).

Ce que j'aime dans SIP c'est que tous les opérateurs (que ce soit Wengo, FWD, voipuser, sipphone, etc) peuvent tous communiquer entre eux sans aucune difficulté et en utilisant n'importe quel logiciel libre implementant SIP. Ca c'est la liberté. J'ai pas ça avec Skype.

Django est un peu en retard au niveau d'AJAX, vu qu'ils réécrivent tout de zéro. TurboGears, aussi développé en Python (http://www.turbogears.org/ ) est beaucoup plus avancé (AMHA) sur beaucoup de niveau, et est beaucoup plus proche, voire mieux dans certains cas (AJAX par exemple, ou SQLObject pour le mapping entre les objets et la base de données) que RoR. Par exemple, un graph UML automatique (http://www.checkandshare.com/blog/?p=27 ) en AJAX a été ajouté à l'admin pour voir/modifier les données de la base.

TurboGears a *aussi* un screencast (http://www.turbogears.org/docs/wiki20/20MinuteWiki.mov ) de démonstration.

Le problème c'est plutôt Ruby, qui ne supporte pas les threads natives. C'est une des raisons pour lesquelles c'est super lent. Pour chaque changement de contexte, Ruby simule le thread, alors pour recopier/remettre les données, il fait plein de memcpy.

Pour le Global Lock (GIL) de Python, d'habitude ce n'est vraiment pas un problème. La plupart des applis se découpent très facilement en différents services (et c'est plus propre). Certaines applis (Twisted pour n'en citer qu'un exemple) n'utilisent pas du tout les threads, et ça fonctionne très bien et c'est super rapide.

Effectivement, il semble que je me sois trompé. Je pensais que cela voulait dire "à l'opposé", mais visiblement, c'est l'opposé :-)

à l'instar de certaines distributions similaires comme Knoppix, de découvrir le système GNU/Linux sur n'importe quel ordinateur x86 sans rien installer sur le disque dur

De ce que je lis de l'annonce, on a l'impression que la "Move" est la seule distribution à fonctionner sur CD et sans aucune nécessité d'accès à un disque dur. C'est bizarre, je boote très souvent sur Knoppix, et je n'ai absolument pas besoin de disque dur pour "découvrir le système GNU/Linux".
Est-ce que cette news n'est pas un peu biaisée, voire écrite par qq'un travaillant chez MandarkeSoft ???

C'est bizarre, je pensais que Lustre était beaucoup plus avancé qu'Intermezzo. Historiquement, Intermezzo est une évolution de Coda, qui est une évolution de NFS :-) Ni Intermezzo ni Coda n'ont su décoller, mais pas pour les même raisons. Pour Coda, c'est parce qu'il n'a jamais eu une seule version stable qui puisse être utilisée en production. Pour Intermezzo, il n'a jamais vraiment été complet, il y a eu des version "light" d'Intermezzo mais sans grand intérêt (un genre de rsync par le web).
Du coté de Lustre, les fonctionnalités sont un peu différentes puisque le but initial était la gestion/fusion d'un grand nombre de disques répartis sur un grand nombre de machines différentes pour des applicatifs du genre clusters de calcul. Une sorte de PVFS (Parallel Virtual FileSystem), mais qui crashe pas :-).
Si en plus, les développeurs de Lustre rajoutent les fonctionnalités de gestion en mode déconnecté, on pourra peut-être l'utiliser à la place de NFS, en tant que FS distribué pour fichiers ?

Que du bonheur!

Tu parles des anciens "Service Processors". Les nouveaux serveurs IBM intègrent des nouvelles puces, qui sont administrables sans module dans le kernel, tout par le réseau en utilisant le protocole IPMI (développé par Intel, http://www.intel.com/design/servers/ipmi/(...) ), protocole plus ou moins standard qui a le mérite d'être assez bien documenté. A partir du x335, les services processors sont accessibles en IPMI.

Donc: apt-get install ipmi-tools

Ce que je dis, c'est que cela n'était pas le cas aux début de Mandrake. C'est aussi une des raisons pour lesquelles Mandrake s'est développé rapidement. Personne ne voulait intégrer KDE dans la distrib parce que leur licence était INCOMPATIBLE avec la GPL, c'est un fait.
Mais cela n'a pas gêné MandrakeSoft. De même, à l'époque, le portage d'applis GPL avec l'interface Qt n'a pas non plus gêné MandrakeSoft.

Je n'appelle pas cela "respecter la GPL". Ne pas suivre toutes les règles édictées par la licence (qui n'inclue pas que "redonner les sources", comme beaucoup pensent) peut amener à la destruction de Linux.
Pour TrollTech, je pense vraiment que l'on a eu de la chance. Si cela avait été une autre société, cela aurait pu être vraiment plus grave.

Donc, je maintient ce que j'ai dit, MandrakeSoft s'est comporté comme une société irresponsable, violant les règles les plus élémentaires de la GPL.

Sur l'url donnée en référence (http://www.mandrakesoft.com/company/investors/newsletter/sn040214?w(...)) on peut lire "MandrakeSoft est l'un des tous premiers éditeurs mondiaux de systèmes d'exploitation Linux et de logiciels libres (accès libre au code source publié selon les termes de la GPL - General Public License".

Personnellement, je trouve cela un petit peu exagéré, voire négationniste. Il faudrait voir après combien de société/distributions on se considère encore parmi les "premiers". Il y a quand même une dizaine de distributions qui étaient avant. Et pour le coup du "respectant la GPL", il faudrait que les anciens de Mandrake m'expliquent cette relation de "GPL" avec l'ajout de logiciels qui n'était pas du tout GPL dans du GPL (toute la suite KDE, basée à l'époque sur une licence complètement non compatible avec la GPL).

Mais bon, cette lettre d'information, est à destination des "actionnaires", qui eux, ne lisent jamais LinuxFR, alors ils ne sauront jamais...

Arf, Firefox, c'est vraiment trop nul. Firebird, avait le mérite de correspondre à un "animal" mythique, le phoenix. Mais Firefox...
Pour la version française, ça sera "Renard qui brûle", ou "Renard qui a le feu au derrière" (encore mieux :-)))

Hum, ce n'est pas parce qu'il y a un site en hébreu (il n'y a pas de 'x' à la langue hébraïque) appartenant à Microsoft, que Microsoft "supporte l'hébreu".
Le problème, pour être précis, vient du refus de Microsoft de faire fonctionner/porter le support de l'hébreu dans leur suite Office sous Mac.

Sur Windows X/Y/Z, il n'y a aucun problème.

Non, il ne faut pas dire "détruire", mais "démonter". Ca a bien marché pour José Bové...

Sur la page de garde du projet Rei:
"The current work, before going to Milestone 5, is to rewritte the code in Python, and to use the NebulaDevice engine".

Erlang est peut etre pas si bien, si ils reecrivent tout en python ?
Ou j'ai pas compris le sens du message ?

Parce que Jabber n'est pas du P2P, tout simplement. Jabber nécessite un (ou plusieurs) serveurs centraux, ce qui n'est pas le cas de WASTE. Avec WASTE, on peut se connecter derrière un firewall, si les deux parties sont connectées à une tierce qui elle, est accessible directement (sur internet).

Je pense que c'est plus prévu pour les caches du coté des clients. Dans une grande majorité des cas (AMHA) les gens qui se connectent à internet passent par un proxy, que ce soit le proxy de leur fournisseur d'accès (quel FAI ne propose pas de proxy, quand ce n'est pas un cluster de proxy comme chez AOL :-) ou celui de leur société.

> Je m'abreuve aux meilleures sources (shane@zope.org)
> http://mail.zope.org/pipermail/zope-coders/2002(...)

C'est vrai que Shane Hathaway est le dieu vivant du Zope, mais tu devrait regarder ta référence un peu mieux. Ce n'est pas Shane qui a dit qu'il pense que Zope n'est pas assez robuste (FUD), c'est un certain Toby Dickenson. D'ailleurs Shane défend la robustesse de Zope dans son mail, je te ferais remarquer. Lis le mail jusqu'au bout :-)

Concernant cette référence, je suis tout à fait d'accord:
"[Zope] is not as prepared to deal with that threat as Apache or Squid."
Ce qui est évident. Donc, je confirme: FUD.

De même dans la conclusion de ce mail, il est bien dit que Zope n'a pas spécialement de problème de DoS, autres que des personnes envoyant des requetes répétées. Mais comme je l'ai dit, *tous* les serveurs applicatifs y sont vulnérables.
"But I don't think it's any more vulnerable to other kinds of attacks
than other HTTP servers. It doesn't use the filesystem and never runs
with root privileges".

Donc, je ne vois pas du tout en quoi ce mail vient défendre tes arguments, je dirais même au contraire :-)

Pour le SSL, Zope possède deux modules pour faire du SSL de façon native, l'un étant semi-extérieur, et l'autre permettant de gérer les certificats en interne dans Zope, ce qui n'est pas le cas avec Apache.

Alors, je ne vois toujours pas de raison valable d'utiliser Apache.

Pourquoi mets-tu un deuxième cache ? Tu utilises déjà le cache de Zope. Si tu mets en cache (HTTP cache et RAM cache) tes objets correctement, tu n'as pas besoin d'Apache.

En dehors de ce petit FUD, je dois dire que ce que tu dis correspond à *tous* les logiciels fonctionnant de manière dynamique.

Le but de Zope est d'utiliser ses fonctionnalités *applicatives* telles que les workflows, la gestion de la sécurité, la génération dynamique de contenu adapté à tout un ensemble de paramètres/autres objets. Tout logiciel qui fonctionne de cette manière est vulnérable à des dénis de services si quelqu'un fait des requêtes en masse (quoique, ça fait plus de hits :-).

Mettre un Apache ou un Squid ne servira à rien dans ce cas, puisque les pages sont supposées être générées différemment (quasiment) à chaque fois). Si ce n'est pas le cas, alors n'utilise pas Zope, utilise un Templeet ou équivalent.

Pour éviter ces problèmes, faire de la répartition de charge est une solution, ou faire de la qualité de service sur le firewall devant, sont quelques-unes des possiblités qui me viennent en tête. Mais mettre un Apache, non, pas vraiment.

> Oui, surtout que l'on met rarement (voire jamais) Zope en frontal direct.

D'où tiens tu ces informations ? Est-ce que tu installes souvent des Zope chez des clients ? L'installation de Zope avec Apache/Squid était intéressante il y a plus de deux ans, pour profiter du cache pour les images, ou pour le virtualhost. Mais cela fait un bon moment que cela n'est plus nécessaire. Zope intègre une gestion des virtual host beaucoup plus fine, et intègre des objets de type 'cache' (plusieurs types, même) qui peuvent être associés à n'importe lequel des éléments de ton zope. Cela peut être une partie de page, un calcul, ou des pages entières.

Je recommande d'installer Zope en frontal, sans aucune hésitation.

Vaut mieux pas que tu paries, alors. Une société qui a déposé le bilan,racheter une autre...hum hum. Enfin, Alcove n'a pas vraiment déposé le bilan, elle s'est fait racheté par eGenious, qui est pas très orienté Linux...

Ce n'est plus "VA Linux", mais VA Software. Ils ont changé de nom, et *abandonné* Linux. Dans tous les sens du terme.

N'y avait-il pas un projet aussi pour Mozilla, ayant pour but de rajouter le support de GPG ?
Ya plus de nouvelles ?

Perl, Python, Ruby, tout ça c'est nul !

Jetez un oeil sur Intercal, un super langage, créé en 1973, qui a de nombreux modules, et a une syntaxe des plus claires !

http://bears.ece.ucsb.edu/personnel/astornet/humor/humor45.html(...)