Je me cherche un lecteur RSS pour OSX. Je viens de tester très
superficiellement NewsFire. Je n'ai pas encore eu le temps de me faire
une opinion, mais je cherche déjà une alternative gratuite.
Mais bon, si il n'y a pas mieux, je me le payerai.
Hum... Je ne connais pas les finesses de launchproxy, mais il me semble qu'avec inetd on peut gérer des délais même assez longs : par exemple quand on passe par tcp_wrappers qui va faire quelques vérifs pouvant demander le lancement d'autres processus avant d'autoriser le dialogue.
Si je ne me trompe pas normalement on devrait lancer un process quand on a une ouverture de connexion et ce processuss prend ses entrées dans stdin. Il ne faut pas que ce procuss fasse de lecture sur son entrée tant que la connexion n'est pas établie.
yep... avec inetd c'est plus souple à ce niveau. Je n'ai pas fait de ktrace pour launchproxy ou launchd pour savoir qui reçoit vraiment les requêtes réseau, qui les transmet ou ne les transmet pas. Par contre, j'ai fait un tcpdump sur le port ouvert local, et je vois bien mon appli balancer ses requetes dedans, alors que launchproxy est juste en train de se lancer.
Oui mais ça c'est normal : les paquets arrivent et devraient être bufferisés au niveau du seveur avant d'être transmis pour traitement. Quant tu envoies tes paquets, tu n'as pas de contrôle sur la réception. Donc tu envoies. Après soit ils sont traités en temps utile, soit réémis, soit le client part sur un timeout. La présence des paquets sur le réseau (quand bien même ce serait une interface loopback) est normale à ce momment là.
C'est juste que le proxy ne devrait (doit) pas les lire (il ne devrait pas y avoir d'appel read sur le socket). Il doivent rester au niveau des buffers de la pile tcp/ip. Les reads devraient être fait uniquement par l'appli.
Prochaine étape : ktrace, le seul problème c'est que launchd c'est vaste, je vais pas pouvoir le tracer tres longtemps sans me retrouver avec des tonnes de choses qui n'ont rien à voir avec ce que je suis en train de faire :)
:) suffit d'avoir un gros disque :) Ça m'arrive de faire des truss (ktrace solaris) sur inetd.
FiLH
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> writes:
In article <uxlktgvq7nwer@noorg.org>, FiLH <filh@filh.org> wrote:
Hum... Je ne connais pas les finesses de launchproxy, mais il me
semble qu'avec inetd on peut gérer des délais même assez longs : par
exemple quand on passe par tcp_wrappers qui va faire quelques vérifs
pouvant demander le lancement d'autres processus avant d'autoriser le
dialogue.
Si je ne me trompe pas normalement on devrait lancer un process quand
on a une ouverture de connexion et ce processuss prend ses entrées dans
stdin. Il ne faut pas que ce procuss fasse de lecture sur son entrée
tant que la connexion n'est pas établie.
yep... avec inetd c'est plus souple à ce niveau.
Je n'ai pas fait de ktrace pour launchproxy ou launchd pour savoir qui
reçoit vraiment les requêtes réseau, qui les transmet ou ne les transmet
pas.
Par contre, j'ai fait un tcpdump sur le port ouvert local, et je vois
bien mon appli balancer ses requetes dedans, alors que launchproxy est
juste en train de se lancer.
Oui mais ça c'est normal : les paquets arrivent et devraient être
bufferisés au niveau du seveur avant d'être transmis pour traitement.
Quant tu envoies tes paquets, tu n'as pas de contrôle sur la
réception. Donc tu envoies. Après soit ils sont traités en temps
utile, soit réémis, soit le client part sur un timeout.
La présence des paquets sur le réseau (quand bien même ce serait une
interface loopback) est normale à ce momment là.
C'est juste que le proxy ne devrait (doit) pas les lire (il ne devrait
pas y avoir d'appel read sur le socket). Il doivent rester au niveau
des buffers de la pile tcp/ip.
Les reads devraient être fait uniquement par l'appli.
Prochaine étape : ktrace, le seul problème c'est que launchd c'est
vaste, je vais pas pouvoir le tracer tres longtemps sans me retrouver
avec des tonnes de choses qui n'ont rien à voir avec ce que je suis en
train de faire :)
:) suffit d'avoir un gros disque :) Ça m'arrive de faire des truss
(ktrace solaris) sur inetd.
FiLH
--
FiLH photography. A taste of freedom in a conventional world.
Web: http://www.filh.org e-mail filh@filh.org
FAQ fr.rec.photo : http://frp.parisv.com/
Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
Hum... Je ne connais pas les finesses de launchproxy, mais il me semble qu'avec inetd on peut gérer des délais même assez longs : par exemple quand on passe par tcp_wrappers qui va faire quelques vérifs pouvant demander le lancement d'autres processus avant d'autoriser le dialogue.
Si je ne me trompe pas normalement on devrait lancer un process quand on a une ouverture de connexion et ce processuss prend ses entrées dans stdin. Il ne faut pas que ce procuss fasse de lecture sur son entrée tant que la connexion n'est pas établie.
yep... avec inetd c'est plus souple à ce niveau. Je n'ai pas fait de ktrace pour launchproxy ou launchd pour savoir qui reçoit vraiment les requêtes réseau, qui les transmet ou ne les transmet pas. Par contre, j'ai fait un tcpdump sur le port ouvert local, et je vois bien mon appli balancer ses requetes dedans, alors que launchproxy est juste en train de se lancer.
Oui mais ça c'est normal : les paquets arrivent et devraient être bufferisés au niveau du seveur avant d'être transmis pour traitement. Quant tu envoies tes paquets, tu n'as pas de contrôle sur la réception. Donc tu envoies. Après soit ils sont traités en temps utile, soit réémis, soit le client part sur un timeout. La présence des paquets sur le réseau (quand bien même ce serait une interface loopback) est normale à ce momment là.
C'est juste que le proxy ne devrait (doit) pas les lire (il ne devrait pas y avoir d'appel read sur le socket). Il doivent rester au niveau des buffers de la pile tcp/ip. Les reads devraient être fait uniquement par l'appli.
Prochaine étape : ktrace, le seul problème c'est que launchd c'est vaste, je vais pas pouvoir le tracer tres longtemps sans me retrouver avec des tonnes de choses qui n'ont rien à voir avec ce que je suis en train de faire :)
:) suffit d'avoir un gros disque :) Ça m'arrive de faire des truss (ktrace solaris) sur inetd.
FiLH
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
patpro ~ Patrick Proniewski
In article , FiLH wrote:
Par contre, j'ai fait un tcpdump sur le port ouvert local, et je vois bien mon appli balancer ses requetes dedans, alors que launchproxy est juste en train de se lancer.
Oui mais ça c'est normal : ...
vi je sais
C'est juste que le proxy ne devrait (doit) pas les lire (il ne devrait pas y avoir d'appel read sur le socket). Il doivent rester au niveau des buffers de la pile tcp/ip. Les reads devraient être fait uniquement par l'appli.
la par contre j'ai pas vérifié, c'est le but du ktrace.
Prochaine étape : ktrace, le seul problème c'est que launchd c'est vaste, je vais pas pouvoir le tracer tres longtemps sans me retrouver avec des tonnes de choses qui n'ont rien à voir avec ce que je suis en train de faire :)
:) suffit d'avoir un gros disque :) Ça m'arrive de faire des truss (ktrace solaris) sur inetd.
truss c'est vachement moins bavard que ktrace :) (en tout cas le truss de freebsd comparé au ktrace de MacOS X)
patpro
In article <ux8xpgvnenwer@noorg.org>, FiLH <filh@filh.org> wrote:
Par contre, j'ai fait un tcpdump sur le port ouvert local, et je vois
bien mon appli balancer ses requetes dedans, alors que launchproxy est
juste en train de se lancer.
Oui mais ça c'est normal : ...
vi je sais
C'est juste que le proxy ne devrait (doit) pas les lire (il ne devrait
pas y avoir d'appel read sur le socket). Il doivent rester au niveau
des buffers de la pile tcp/ip.
Les reads devraient être fait uniquement par l'appli.
la par contre j'ai pas vérifié, c'est le but du ktrace.
Prochaine étape : ktrace, le seul problème c'est que launchd c'est
vaste, je vais pas pouvoir le tracer tres longtemps sans me retrouver
avec des tonnes de choses qui n'ont rien à voir avec ce que je suis en
train de faire :)
:) suffit d'avoir un gros disque :) Ça m'arrive de faire des truss
(ktrace solaris) sur inetd.
truss c'est vachement moins bavard que ktrace :) (en tout cas le truss
de freebsd comparé au ktrace de MacOS X)
Par contre, j'ai fait un tcpdump sur le port ouvert local, et je vois bien mon appli balancer ses requetes dedans, alors que launchproxy est juste en train de se lancer.
Oui mais ça c'est normal : ...
vi je sais
C'est juste que le proxy ne devrait (doit) pas les lire (il ne devrait pas y avoir d'appel read sur le socket). Il doivent rester au niveau des buffers de la pile tcp/ip. Les reads devraient être fait uniquement par l'appli.
la par contre j'ai pas vérifié, c'est le but du ktrace.
Prochaine étape : ktrace, le seul problème c'est que launchd c'est vaste, je vais pas pouvoir le tracer tres longtemps sans me retrouver avec des tonnes de choses qui n'ont rien à voir avec ce que je suis en train de faire :)
:) suffit d'avoir un gros disque :) Ça m'arrive de faire des truss (ktrace solaris) sur inetd.
truss c'est vachement moins bavard que ktrace :) (en tout cas le truss de freebsd comparé au ktrace de MacOS X)
patpro
filh
patpro ~ Patrick Proniewski wrote:
:) suffit d'avoir un gros disque :) Ça m'arrive de faire des truss (ktrace solaris) sur inetd.
truss c'est vachement moins bavard que ktrace :) (en tout cas le truss de freebsd comparé au ktrace de MacOS X)
Le truss de solaris 9 permet même de tracer les appels de fonction. Mais par défaut il est suffisament concis pour être lisible. ktrace l'est moins :)
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> wrote:
:) suffit d'avoir un gros disque :) Ça m'arrive de faire des truss
(ktrace solaris) sur inetd.
truss c'est vachement moins bavard que ktrace :) (en tout cas le truss
de freebsd comparé au ktrace de MacOS X)
Le truss de solaris 9 permet même de tracer les appels de fonction.
Mais par défaut il est suffisament concis pour être lisible.
ktrace l'est moins :)
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
:) suffit d'avoir un gros disque :) Ça m'arrive de faire des truss (ktrace solaris) sur inetd.
truss c'est vachement moins bavard que ktrace :) (en tout cas le truss de freebsd comparé au ktrace de MacOS X)
Le truss de solaris 9 permet même de tracer les appels de fonction. Mais par défaut il est suffisament concis pour être lisible. ktrace l'est moins :)
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
patpro ~ Patrick Proniewski
In article <1hevcrt.1m4b2gf1pmzlmmN%, (FiLH) wrote:
patpro ~ Patrick Proniewski wrote:
:) suffit d'avoir un gros disque :) Ça m'arrive de faire des truss (ktrace solaris) sur inetd.
truss c'est vachement moins bavard que ktrace :) (en tout cas le truss de freebsd comparé au ktrace de MacOS X)
Le truss de solaris 9 permet même de tracer les appels de fonction. Mais par défaut il est suffisament concis pour être lisible. ktrace l'est moins :)
bon, ça dépasse mes compétences tout ça. Au final j'ai fait mon ktrace, mais je ne vois rien à en tirer :/
patpro
In article <1hevcrt.1m4b2gf1pmzlmmN%filh@filh.orgie>,
filh@filh.orgie (FiLH) wrote:
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> wrote:
:) suffit d'avoir un gros disque :) Ça m'arrive de faire des truss
(ktrace solaris) sur inetd.
truss c'est vachement moins bavard que ktrace :) (en tout cas le truss
de freebsd comparé au ktrace de MacOS X)
Le truss de solaris 9 permet même de tracer les appels de fonction.
Mais par défaut il est suffisament concis pour être lisible.
ktrace l'est moins :)
bon, ça dépasse mes compétences tout ça. Au final j'ai fait mon ktrace,
mais je ne vois rien à en tirer :/
In article <1hevcrt.1m4b2gf1pmzlmmN%, (FiLH) wrote:
patpro ~ Patrick Proniewski wrote:
:) suffit d'avoir un gros disque :) Ça m'arrive de faire des truss (ktrace solaris) sur inetd.
truss c'est vachement moins bavard que ktrace :) (en tout cas le truss de freebsd comparé au ktrace de MacOS X)
Le truss de solaris 9 permet même de tracer les appels de fonction. Mais par défaut il est suffisament concis pour être lisible. ktrace l'est moins :)
bon, ça dépasse mes compétences tout ça. Au final j'ai fait mon ktrace, mais je ne vois rien à en tirer :/
patpro
sanji
patpro ~ Patrick Proniewski wrote:
Je me cherche un lecteur RSS pour OSX. Je viens de tester très superficiellement NewsFire. Je n'ai pas encore eu le temps de me faire une opinion, mais je cherche déjà une alternative gratuite. Mais bon, si il n'y a pas mieux, je me le payerai.
De mon côté, j'utilise NetNewsWire Light. J'en teste (à mon humble niveau) régulièrement d'autres, et celui-ci garde ma préférence. Simple, efficace, bien intégré...
-- Sanji
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> wrote:
Je me cherche un lecteur RSS pour OSX. Je viens de tester très
superficiellement NewsFire. Je n'ai pas encore eu le temps de me faire
une opinion, mais je cherche déjà une alternative gratuite.
Mais bon, si il n'y a pas mieux, je me le payerai.
De mon côté, j'utilise NetNewsWire Light. J'en teste (à mon humble
niveau) régulièrement d'autres, et celui-ci garde ma préférence. Simple,
efficace, bien intégré...
Je me cherche un lecteur RSS pour OSX. Je viens de tester très superficiellement NewsFire. Je n'ai pas encore eu le temps de me faire une opinion, mais je cherche déjà une alternative gratuite. Mais bon, si il n'y a pas mieux, je me le payerai.
De mon côté, j'utilise NetNewsWire Light. J'en teste (à mon humble niveau) régulièrement d'autres, et celui-ci garde ma préférence. Simple, efficace, bien intégré...
-- Sanji
Vincent Lefevre
Dans l'article , patpro ~ Patrick Proniewski écrit:
Je me cherche un lecteur RSS pour OSX. Je viens de tester très superficiellement NewsFire. Je n'ai pas encore eu le temps de me faire une opinion, mais je cherche déjà une alternative gratuite. Mais bon, si il n'y a pas mieux, je me le payerai.
J'utilise Liferea, qui est un lecteur basé sur GTK+. Je peux ainsi utiliser le même lecteur que sous Linux.
Dans l'article <patpro-694AF2.09365529042006@localhost>,
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> écrit:
Je me cherche un lecteur RSS pour OSX. Je viens de tester très
superficiellement NewsFire. Je n'ai pas encore eu le temps de me faire
une opinion, mais je cherche déjà une alternative gratuite.
Mais bon, si il n'y a pas mieux, je me le payerai.
J'utilise Liferea, qui est un lecteur basé sur GTK+. Je peux ainsi
utiliser le même lecteur que sous Linux.
Dans l'article , patpro ~ Patrick Proniewski écrit:
Je me cherche un lecteur RSS pour OSX. Je viens de tester très superficiellement NewsFire. Je n'ai pas encore eu le temps de me faire une opinion, mais je cherche déjà une alternative gratuite. Mais bon, si il n'y a pas mieux, je me le payerai.
J'utilise Liferea, qui est un lecteur basé sur GTK+. Je peux ainsi utiliser le même lecteur que sous Linux.
