Ça marche tout seul, ça compresse à des taux pas humains, c'est utilisable même sur un ZX81... En lisant cet article, la première chose qui m'est venue à l'esprit était «i2bp» :-)
Pour avoir développé sur ce genre de machine, je dois admettre qua ça fonctionne... pour être précis, je dirais que ça arrive à marcher là où d'autres systèmes courrent :-)
Tout ça pour dire que je ne connais pas la raison historique qui a donné naissance au système HPUX (il devait bien y avoir un besoin quelque part, non?) mais maintenant je ne comprends pas pourquoi certains s'acharnent à l'utiliser.
ils ont vérifié qu'il n'y avait pas de problème à utiliser ce nom
Il ne doit pas y avoir de problème légal, mais ça ne va pas être simple d'expliquer aux clients qu'on fait des applications web reposant sur Firebird pour les données et dont l'interface esqt compatible Firebird...
Parce que tout le monde n'aime pas perdre sa journée à trouver les paquets -dev qu'il faut installer afin que la compilation se passe bien... Avant, je me compilais mon mplayer, mais le jour où j'ai réinstallé mon système, ça m'a tellement pris la tête que finalement je me suis rabattu sur un bon vieux "apt-get install mplayer".
Je ne sais pas si les gens qui lisent DLFP sont contre les Dean Markley, mais en attendant il y a eu comme un vent de [-] qui a soufflé sur ce thread!!
C'est bien là le seul point commun au niveau des tests effectués.
On sait très bien qu'en demandant x fois le même document à Templeet il ne sera généré qu'une seule fois et ensuite il sera toujours renvoyé par Apache donc je ne vois pas comment on peut appeler ça un test de Templeet.
À la limite, ils auraient comparé la vitesse de génération d'un même document dans les différents langages de template de ces outils, ça aurait pu commencer à vouloir dire quelque chose (et encore, on peut toujours critiquer la façon de coder dans chaque langage) mais là je soutiens que c'est du n'importe quoi...
Pourquoi ne pas tester l'adhérence sur sol humide (toujours le même taux d'humidité) d'un char Leclerc à 10km/h, d'une Ferrari à 200km/h (en seconde, quoi) et d'une BX à 160km/h?
En fait, les premières semaines le son est sympa, ensuite pendant quelques temps c'est pas ce que je préfère, mais c'est vrai qu'ensuite ça devient très intéressant... bon, par contre il faut savoir que j'ai une guitare pourrie et que je sature le son (MT2 roulaiz) donc ça peut ne pas convenir à tout le monde :-)
Je dois avouer que j'ai vu beaucoup de cas où Zope était en frontal...
Boarf, on voit aussi des IIS et des Exchange branché directement sur Internet... ce n'est pas pour autant que c'est une bonne idée :-)
Mettre Apache devant fait tellement gagner que ça ?
Ça peut faire énormément chutter la charge du serveur Zope, mais ça demande un peu de travail (ie: ajouter Apache ne fait généralement pas gagner de perf. s'il n'y a pas un minimum de gestion de cache déjà en place sur Zope).
Ca m'intéresse, car mon OpenBrick a un p'tit Zope dessus, alors si je pouvais l'accélérer facilement, ça ne me dérangerait pas...
Je pense que c'est plus prévu pour les caches du coté des clients.
Personnellement, je ne sais pas pour quoi c'était prévu, mais je vois à quoi ça sert :-) Je vois Zope plus comme un moteur de génération de document que comme un serveur web... bien sûr, la gestion des entêtes HTTP me ramène souvent à la réalité.
Dans le cas d'un Zope sans reverse-proxy cache, un document demandé par x clients différents n'utilisant le même proxy fera travailler Zope x fois. En utilisant un reverse-proxy cache et un "HTTP Cache", seul le premier client fera travailler Zope, les autres étant directement servis par le reverse proxy... je trouve que ça fait quand même une grosse différence au niveau de la charge du serveur Zope!
Un "RAM Cache" permet d'éviter la génération de certaines parties de documents dans Zope. Par exemple, sur LinuxFR, l'entête des pages est statique (ou presque, y'a quand même la date), mais il est quand même souhaitable de gérer les listes de liens autrement qu'à la main dans le code HTML... dans ce cas, on crée un document chargé de faire le rendu de cette partie de la page et on l'associe à un "RAM Cache" chargé de garder la page générée pendant x secondes (ce n'est qu'un exemple très très simpliste).
Un "HTTP Cache" permet d'ajouter des entêtes de gestion de cache aux réponses HTTP du serveur Zope... ces entêtes servent à annoncer aux navigateurs pendant combien de temps les documents servis doivent être gardés en cache (c'est très utile pour les images et les CSS, entre autre). En plaçant un Apache ou un Squid devant un Zope, les documents contenant de tels entêtes peuvent être gardés sur le reverse-proxy; ainsi, la première requête sera relayée à Zope, et toutes les suivantes seront directement servies par le reverse-proxy, et ce tant que le document n'aura pas expiré du cache.
Si tu maîtrises assez Zope pour m'aider à le paramétrer à son avantage, je prends. Je me suis contenté de vérifier l'activation du cache ainsi que sa taille, qui m'a semblé correcte.
Je ne peux pas franchement dire que je maîtrise Zope, d'autant que j'ai encore quelques problèmes avec les paramètres de la ZODB, mais l'utilisation d'"Accelerated HTTP Cache Manager" associés à un frontal Apache en reverse-proxy/cache et de "RAM Cache Manager" m'a déjà permis d'atteindre des performances très raisonnables, même sur des machine de type VIA Eden. Par contre, j'ai du m'embrouiller dans certains paramètres Apache car il lui arrive de nettoyer son cache sans pour autant redemander les pages à Zope... résultat: au bout de quelques heures, Apache renvoie des documents vides :-(
Ouf, je ne suis pas le seul à être étonné par les données de ce benchmark.
Après avoir regardé comment les tests ont été réalisés, j'aurais tendance à devenir grossier, surtout quand j'entends parler de graphiques parlants: je ne vois pas bien comment on peut comparer des valeurs qui ne veulent rien dire entre elles. À part la comparaison Apache/Templeet qui semble se baser sur le même document, les autres serveurs sont utilisés complètement différemment...
En voyant la configuration Apache du serveur Templeet, je comprends enfin d'où viennent ses performances dont tout le monde parle tant :-) Par contre, il faut savoir que Zope dispose de ce genre de mise en cache des données, même si ce cache n'est géré qu'en mémoire. Il faut aussi noter que les méchanismes d'invalidation des caches sous Zope seraient sûrement à revoir: pour l'instant, je n'ai pas trouvé comment ne retirer que certaines données d'un cache, je suis donc obligé de vider entièrement un cache même si je sais que certaines des données auraient pu y être gardées... heureusement qu'il est possible de créer plusieurs caches!
je crois que c'est le client de référence pour les gens qui travaillent sur le protocole
Quand je vois qu'un bug comme celui-là http://sourceforge.net/tracker/index.php?func=detail&aid=420576&group_id=1934&atid=101934 n'a pas pu être corrigé en 2 ans, j'espère que ce n'est pas ce qu'on appelle la référence... personnellement, je m'en sers, et étant abonné à l'ADSL je n'ai pas souvent de déconnexion, mais cela est un gros problème pour les internautes sur Numeris ou RTC.
À part ça, il faut reconnaître que ça marche plutôt bien; c'est d'ailleurs à mon avis le client Jabber dont le support SSL est le plus simple à installer. Tkabber est pas mal non plus, mais je trouve que le SSL est trop compliqué à mettre en place.
- dans un premier temps, BSEsel tente d'expliquer à mldonkey qu'un client edonkey n'a pas besoin de se connecter à plusieurs serveurs en TCP pour être efficace; ses arguments sont plus que valables
- ensuite, mldonkey essaye de se la péter en raccontant qu'il a fait plein de recherches sur le protocole edonkey et tout et tout, mais ne répond pas aux arguments de BSEsel
- avec le temps BSEsel se fait enguirlander par pas mal de monde et finit par s'emporter (mais je trouve qu'il a raison), expliquant que la seule chose qu'il n'a jamais reprochée au logiciel mldonkey, c'est de saturer inutilement les serveurs edonkey car il réserve des slots TCP sur plusieurs serveurs
- arrive alors un gentil monsieur appelé sergio qui n'a pas d'autre but que d'énerver BSEsel
- finalement, mldonkey finit par faire ce qu'il aurait du faire depuis le début: il demande des détails sur le protocole edonkey; il semblerait qu'il n'avait pas trop d'info sur la partie UDP alors qu'en début de thread il semblait expliquer que ce n'est pas un simple utilisateur qui allait lui dire comment marche le réseau edonkey; c'est un peu ridicule de sa part, mais au moins son comportement évolue dans le bon sens
À la fin, tout s'arrange (mldonkey et BSEsel se marièrent et eurent beaucoup d'enfants, sergio quand à lui croupit dans une prison turque) même si, comme le dit un message en début de thread, toutes les questions n'ont pas encore trouvées leurs réponses... la vérité est ailleurs :-)
la France est au bord de la faillite et la majorité des Français ne s'en rend pas compte
Tant que le banquier ne m'appelle pas pour me signaler que mes comptes sont dans le rouge, c'est que tout va bien :-) D'autant que la France a un découvert autorisé assez bon...
Pour avoir utilisé Interbase et Firebird (le deuxième est l'évolution en libre du premier) sous Linux, associé à Zope, je dois dire que cette base de données marche mais n'est pas pratique du tout. Les fonctionnalités ne manquent pas (contraintes, triggers...) mais je me souviens avoir passé des jours à me prendre la tête avec son SQL (l'interface en ligne de commande est tout simplement un enfer et les petites subtilités du langage ont tendance à m'énerver). Depuis peu je suis passé sur Postgres et ça me suffit amplement.
Par contre, vu le nombre de docs sur ce sujet, il semblerait qu'Interbase/Firebird soit intéressant pour développer en Delphi (qui a parlé de Borland?), mais là ce n'est pas mon rayon...
Je suis triste, triste car je suis taxé d'affreux extremiste du libre. Un terrosiste voulant imposé ses idées et ses logiciles aux personnes ne voulant pas en entendre parler.
J'ai connu ce genre d'ambiance il y a plus d'un an dans ma société actuelle; on allait même jusqu'à nous appeler les Ben Ladenn de l'informatique (à un époque où ce nom pouvait être considéré comme insultant, mais on en avait vu d'autres)... depuis, l'un des "extrémistes" a été viré à coup de P au Q, et l'autre est rangé bien sagement dans un placard où on ne vient jamais le déranger. La tension est un peu retombée (faut pas trop s'approcher du placard, on entend encore grogner de temps en temps) et les logiciels libres ne sont plus une priorité... je me demande même si ça l'a été un jour!
Bon, c'est pas tout, mais il est temps que je retourne avec mes balais.
D'après ce qu'ils disent c'est du SSL donc c'est normal que ce ne soit pas lisible... on peut essayer de décrypter en force brute, mais ça risque d'être long. L'autre solution, qu'ils expliquent un tout petit peu, revient à intercepter des appels au système ou aux bibliothèques: la petite application COM, il y a peu de chance qu'elle fasse elle-même le cryptage, elle doit donc à un moment ou un autre avoir quelque part en mémoire le paquet en clair avant d'appeler la fonction de cryptage, ou utiliser une série d'appel pour construire le paquet (déjà, le deuxième cas voudrait dire que les développeurs se sont bien pris la tête pour rien).
À l'époque ou je bidouillais encore un peu sous Windows, il y avait des debuggers qui permettant de stopper le système à tout moment (un peu comme un noyau Linux qui tourne dans un gdb) et de voir ce qu'il s'y passe. On pouvait placer des points d'arrêt un peu partout, éditer le code en direct, faire des recherches dans la mémoire... et justement, s'il s'agit bien d'un paquet SOAP, il me paraît assez simple (enfin bon, ça ne se fait pas en 1 minute) de trouver un '<SOAP:Enveloppe' dans la mémoire de la petite appli COM. Une fois cela trouvé, il ne reste normalement plus qu'à lire la suite.
Quelqu'un a-t-il payé pour lire l'article complet et tester leur super logiciel?
C'est pas que je suis parano, mais pour l'instant nous n'avons aucune information précise, mis à part qu'ils utilisent une fonction cachée de l'API Windows pour obtenir les infos... de mon temps, pour obtenir des informations décryptées, on ne se cassait pas trop la tête: on utilisait un débugger (haaa, le bon vieux SoftIce/WinIce) et on n'appelait pas ça de la magie.
[^] # Re: VNC...
Posté par pas_moi . En réponse à la dépêche NoMachine - Une alternative libre de contrôle de bureau à distance. Évalué à 5.
Ça marche tout seul, ça compresse à des taux pas humains, c'est utilisable même sur un ZX81... En lisant cet article, la première chose qui m'est venue à l'esprit était «i2bp» :-)
[^] # Re: HP conserve CDE au détriment de Gnome
Posté par pas_moi . En réponse à la dépêche HP conserve CDE au détriment de Gnome. Évalué à 3.
Pour avoir développé sur ce genre de machine, je dois admettre qua ça fonctionne... pour être précis, je dirais que ça arrive à marcher là où d'autres systèmes courrent :-)
Tout ça pour dire que je ne connais pas la raison historique qui a donné naissance au système HPUX (il devait bien y avoir un besoin quelque part, non?) mais maintenant je ne comprends pas pourquoi certains s'acharnent à l'utiliser.
[^] # Re: Mplayer...
Posté par pas_moi . En réponse au journal Mplayer.... Évalué à 1.
[^] # Re: Mozilla présente Firebird et Thunderbird
Posté par pas_moi . En réponse à la dépêche Mozilla présente Firebird et Thunderbird. Évalué à 10.
Il ne doit pas y avoir de problème légal, mais ça ne va pas être simple d'expliquer aux clients qu'on fait des applications web reposant sur Firebird pour les données et dont l'interface esqt compatible Firebird...
[^] # Re: Mplayer...
Posté par pas_moi . En réponse au journal Mplayer.... Évalué à 1.
Parce que tout le monde n'aime pas perdre sa journée à trouver les paquets -dev qu'il faut installer afin que la compilation se passe bien... Avant, je me compilais mon mplayer, mais le jour où j'ai réinstallé mon système, ça m'a tellement pris la tête que finalement je me suis rabattu sur un bon vieux "apt-get install mplayer".
[^] # Re: La BSA aide GNU/Linux
Posté par pas_moi . En réponse à la dépêche La BSA aide GNU/Linux. Évalué à -2.
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par pas_moi . En réponse à la dépêche Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick. Évalué à 3.
C'est bien là le seul point commun au niveau des tests effectués.
On sait très bien qu'en demandant x fois le même document à Templeet il ne sera généré qu'une seule fois et ensuite il sera toujours renvoyé par Apache donc je ne vois pas comment on peut appeler ça un test de Templeet.
À la limite, ils auraient comparé la vitesse de génération d'un même document dans les différents langages de template de ces outils, ça aurait pu commencer à vouloir dire quelque chose (et encore, on peut toujours critiquer la façon de coder dans chaque langage) mais là je soutiens que c'est du n'importe quoi...
Pourquoi ne pas tester l'adhérence sur sol humide (toujours le même taux d'humidité) d'un char Leclerc à 10km/h, d'une Ferrari à 200km/h (en seconde, quoi) et d'une BX à 160km/h?
[^] # Re: La BSA aide GNU/Linux
Posté par pas_moi . En réponse à la dépêche La BSA aide GNU/Linux. Évalué à -1.
En fait, les premières semaines le son est sympa, ensuite pendant quelques temps c'est pas ce que je préfère, mais c'est vrai qu'ensuite ça devient très intéressant... bon, par contre il faut savoir que j'ai une guitare pourrie et que je sature le son (MT2 roulaiz) donc ça peut ne pas convenir à tout le monde :-)
[^] # Re: La BSA aide GNU/Linux
Posté par pas_moi . En réponse à la dépêche La BSA aide GNU/Linux. Évalué à -1.
je confirme... mais elles sont quand même meilleures dans les premiers mois
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par pas_moi . En réponse à la dépêche Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick. Évalué à 2.
Boarf, on voit aussi des IIS et des Exchange branché directement sur Internet... ce n'est pas pour autant que c'est une bonne idée :-)
Mettre Apache devant fait tellement gagner que ça ?
Ça peut faire énormément chutter la charge du serveur Zope, mais ça demande un peu de travail (ie: ajouter Apache ne fait généralement pas gagner de perf. s'il n'y a pas un minimum de gestion de cache déjà en place sur Zope).
Ca m'intéresse, car mon OpenBrick a un p'tit Zope dessus, alors si je pouvais l'accélérer facilement, ça ne me dérangerait pas...
Je n'ai pas utilisé ce document mais en le survolant rapidement, il me semble présenter une bonne technique de mise en cache: http://www.nexedi.org/Members/jp/faq/accelerate-zope.stx(...)
Cela n'empêche pas de se renseigner sur la gestion des caches HTTP par les navigateurs et les différents proxys :-)
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par pas_moi . En réponse à la dépêche Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick. Évalué à 2.
Personnellement, je ne sais pas pour quoi c'était prévu, mais je vois à quoi ça sert :-) Je vois Zope plus comme un moteur de génération de document que comme un serveur web... bien sûr, la gestion des entêtes HTTP me ramène souvent à la réalité.
Dans le cas d'un Zope sans reverse-proxy cache, un document demandé par x clients différents n'utilisant le même proxy fera travailler Zope x fois. En utilisant un reverse-proxy cache et un "HTTP Cache", seul le premier client fera travailler Zope, les autres étant directement servis par le reverse proxy... je trouve que ça fait quand même une grosse différence au niveau de la charge du serveur Zope!
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par pas_moi . En réponse à la dépêche Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick. Évalué à 4.
Un "HTTP Cache" permet d'ajouter des entêtes de gestion de cache aux réponses HTTP du serveur Zope... ces entêtes servent à annoncer aux navigateurs pendant combien de temps les documents servis doivent être gardés en cache (c'est très utile pour les images et les CSS, entre autre). En plaçant un Apache ou un Squid devant un Zope, les documents contenant de tels entêtes peuvent être gardés sur le reverse-proxy; ainsi, la première requête sera relayée à Zope, et toutes les suivantes seront directement servies par le reverse-proxy, et ce tant que le document n'aura pas expiré du cache.
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par pas_moi . En réponse à la dépêche Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick. Évalué à 1.
Je ne peux pas franchement dire que je maîtrise Zope, d'autant que j'ai encore quelques problèmes avec les paramètres de la ZODB, mais l'utilisation d'"Accelerated HTTP Cache Manager" associés à un frontal Apache en reverse-proxy/cache et de "RAM Cache Manager" m'a déjà permis d'atteindre des performances très raisonnables, même sur des machine de type VIA Eden. Par contre, j'ai du m'embrouiller dans certains paramètres Apache car il lui arrive de nettoyer son cache sans pour autant redemander les pages à Zope... résultat: au bout de quelques heures, Apache renvoie des documents vides :-(
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par pas_moi . En réponse à la dépêche Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick. Évalué à 8.
Après avoir regardé comment les tests ont été réalisés, j'aurais tendance à devenir grossier, surtout quand j'entends parler de graphiques parlants: je ne vois pas bien comment on peut comparer des valeurs qui ne veulent rien dire entre elles. À part la comparaison Apache/Templeet qui semble se baser sur le même document, les autres serveurs sont utilisés complètement différemment...
En voyant la configuration Apache du serveur Templeet, je comprends enfin d'où viennent ses performances dont tout le monde parle tant :-) Par contre, il faut savoir que Zope dispose de ce genre de mise en cache des données, même si ce cache n'est géré qu'en mémoire. Il faut aussi noter que les méchanismes d'invalidation des caches sous Zope seraient sûrement à revoir: pour l'instant, je n'ai pas trouvé comment ne retirer que certaines données d'un cache, je suis donc obligé de vider entièrement un cache même si je sais que certaines des données auraient pu y être gardées... heureusement qu'il est possible de créer plusieurs caches!
[^] # Re: Playstation 3 sous Linux ?
Posté par pas_moi . En réponse à la dépêche Playstation 3 sous Linux ?. Évalué à -10.
[^] # Re: Besoin de vos expériences sur Jabber
Posté par pas_moi . En réponse au journal Besoin de vos expériences sur Jabber. Évalué à 2.
[^] # Re: On dit BIBLIOTHÈQUE, bordel !
Posté par pas_moi . En réponse au journal On dit BIBLIOTHÈQUE, bordel !. Évalué à 2.
Hein? Y'en a qui disent ça? Moi qui pensait tout savoir, j'en apprends tous les jours :-)
[^] # Re: Ca nous rajeunit pas ... mldonkey 1.0
Posté par pas_moi . En réponse au journal Ca nous rajeunit pas ... mldonkey 1.0. Évalué à 2.
- dans un premier temps, BSEsel tente d'expliquer à mldonkey qu'un client edonkey n'a pas besoin de se connecter à plusieurs serveurs en TCP pour être efficace; ses arguments sont plus que valables
- ensuite, mldonkey essaye de se la péter en raccontant qu'il a fait plein de recherches sur le protocole edonkey et tout et tout, mais ne répond pas aux arguments de BSEsel
- avec le temps BSEsel se fait enguirlander par pas mal de monde et finit par s'emporter (mais je trouve qu'il a raison), expliquant que la seule chose qu'il n'a jamais reprochée au logiciel mldonkey, c'est de saturer inutilement les serveurs edonkey car il réserve des slots TCP sur plusieurs serveurs
- arrive alors un gentil monsieur appelé sergio qui n'a pas d'autre but que d'énerver BSEsel
- finalement, mldonkey finit par faire ce qu'il aurait du faire depuis le début: il demande des détails sur le protocole edonkey; il semblerait qu'il n'avait pas trop d'info sur la partie UDP alors qu'en début de thread il semblait expliquer que ce n'est pas un simple utilisateur qui allait lui dire comment marche le réseau edonkey; c'est un peu ridicule de sa part, mais au moins son comportement évolue dans le bon sens
À la fin, tout s'arrange (mldonkey et BSEsel se marièrent et eurent beaucoup d'enfants, sergio quand à lui croupit dans une prison turque) même si, comme le dit un message en début de thread, toutes les questions n'ont pas encore trouvées leurs réponses... la vérité est ailleurs :-)
[^] # Re: Alsa 0.9 en version stable disponible
Posté par pas_moi . En réponse à la dépêche Alsa 0.9 en version stable disponible. Évalué à 10.
Tu peux continuer à attendre si ça te chante... pour les autres, il y a http://packages.debian.org/cgi-bin/search_packages.pl?keywords=alsa(...)
[^] # Re: Impôts sur le revenu 2002
Posté par pas_moi . En réponse au journal Impôts sur le revenu 2002. Évalué à 0.
Tant que le banquier ne m'appelle pas pour me signaler que mes comptes sont dans le rouge, c'est que tout va bien :-) D'autant que la France a un découvert autorisé assez bon...
[^] # Re: SAPDB 7.4 is out
Posté par pas_moi . En réponse à la dépêche SAPDB 7.4 is out. Évalué à 4.
Par contre, vu le nombre de docs sur ce sujet, il semblerait qu'Interbase/Firebird soit intéressant pour développer en Delphi (qui a parlé de Borland?), mais là ce n'est pas mon rayon...
[^] # Re: Extremiste du libre ou refusd'une domination de fait !?
Posté par pas_moi . En réponse au journal Extremiste du libre ou refusd'une domination de fait !?. Évalué à 1.
Oups... il semblerait qu'il manquasse un petit "extrèmement" dans ma phrase.
# Re: Extremiste du libre ou refusd'une domination de fait !?
Posté par pas_moi . En réponse au journal Extremiste du libre ou refusd'une domination de fait !?. Évalué à 3.
J'ai connu ce genre d'ambiance il y a plus d'un an dans ma société actuelle; on allait même jusqu'à nous appeler les Ben Ladenn de l'informatique (à un époque où ce nom pouvait être considéré comme insultant, mais on en avait vu d'autres)... depuis, l'un des "extrémistes" a été viré à coup de P au Q, et l'autre est rangé bien sagement dans un placard où on ne vient jamais le déranger. La tension est un peu retombée (faut pas trop s'approcher du placard, on entend encore grogner de temps en temps) et les logiciels libres ne sont plus une priorité... je me demande même si ça l'a été un jour!
Bon, c'est pas tout, mais il est temps que je retourne avec mes balais.
[^] # Re: Suuuurpriiiiiise !
Posté par pas_moi . En réponse au journal Suuuurpriiiiiise !. Évalué à 4.
À l'époque ou je bidouillais encore un peu sous Windows, il y avait des debuggers qui permettant de stopper le système à tout moment (un peu comme un noyau Linux qui tourne dans un gdb) et de voir ce qu'il s'y passe. On pouvait placer des points d'arrêt un peu partout, éditer le code en direct, faire des recherches dans la mémoire... et justement, s'il s'agit bien d'un paquet SOAP, il me paraît assez simple (enfin bon, ça ne se fait pas en 1 minute) de trouver un '<SOAP:Enveloppe' dans la mémoire de la petite appli COM. Une fois cela trouvé, il ne reste normalement plus qu'à lire la suite.
# Re: Suuuurpriiiiiise !
Posté par pas_moi . En réponse au journal Suuuurpriiiiiise !. Évalué à 2.
C'est pas que je suis parano, mais pour l'instant nous n'avons aucune information précise, mis à part qu'ils utilisent une fonction cachée de l'API Windows pour obtenir les infos... de mon temps, pour obtenir des informations décryptées, on ne se cassait pas trop la tête: on utilisait un débugger (haaa, le bon vieux SoftIce/WinIce) et on n'appelait pas ça de la magie.