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.
pour moi, des petit Koss, superbes. (in ear?) style bouchon d'oreille,
faciles à porter et avec le son.
J'en ai lu qu'ils étaient plus pour le boum boum que les Sony...
je ne connais pas les sony, mais les koss, je ne les trouve pas boum boum. surtout pour ce que j'écoute principalement (jazz style scofield, zappa)
Le pb est qu'on ne peut pas essayer sans acheter :)
merde, la charte !!
Quelle charte ? laisse tomber, je t'expliquerais plus tard
Ah ok ok ok...
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
daniel patin <marcel.dugenou@free.fr> wrote:
daniel patin <marcel.dugenou@free.fr> wrote:
pour moi, des petit Koss, superbes. (in ear?) style bouchon d'oreille,
faciles à porter et avec le son.
J'en ai lu qu'ils étaient plus pour le boum boum que les Sony...
je ne connais pas les sony, mais les koss, je ne les trouve pas boum
boum. surtout pour ce que j'écoute principalement (jazz style scofield,
zappa)
Le pb est qu'on ne peut pas essayer sans acheter :)
merde, la charte !!
Quelle charte ?
laisse tomber, je t'expliquerais plus tard
Ah ok ok ok...
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
pour moi, des petit Koss, superbes. (in ear?) style bouchon d'oreille,
faciles à porter et avec le son.
J'en ai lu qu'ils étaient plus pour le boum boum que les Sony...
je ne connais pas les sony, mais les koss, je ne les trouve pas boum boum. surtout pour ce que j'écoute principalement (jazz style scofield, zappa)
Le pb est qu'on ne peut pas essayer sans acheter :)
merde, la charte !!
Quelle charte ? laisse tomber, je t'expliquerais plus tard
Ah ok ok ok...
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
filh
patpro ~ Patrick Proniewski wrote:
In article <1heq9mu.71eiyy8ncleiN%, (FiLH) wrote:
patpro ~ patrick proniewski wrote:
In article <1heq8e8.1c9r0rklpmlarN%, (FiLH) wrote:
j'éteins systématiquement le powerbook a chaque déplacement, donc 2 fois par jour.
Quel intérêt ? J'ai 29 jours d'uptime sur un mac qui fait le même trajet.
bah, c'est aussi simple de l'éteindre. :)
Ben... rebooter relancer 10 programmes, reprendre certaines visites de site où j'en été, retapper 15 password, retrouver la musique que j'écoutais, recharger le fichiers dans l'éditeur...
Bref 5 minutes de perdues et plein de fils de travail...
chez moi je bosse surtout sur le G5, alors fermer les fichiers sur le powerbook, les rouvrir sur le G5, tout ca tout ca... casse couille :) En plus l'environnement physique est pas le meme. Au taff je suis en bi écran pour le portable, à la maison j'ai que l'écran intégrer : faut faire le ménage dans les fenêtres.
Quel bazard...
Au boulot j'ai une sun, le mac sert... à des choses diverses et annexes. À la maison c'est ma machine perso. Donc en fait je fais souvent des choses le soir chez moi que je laisse ouvertes au boulot sans y toucher. Bon on va se boire un bibine ? 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:
In article <1heq9mu.71eiyy8ncleiN%filh@filh.orgie>,
filh@filh.orgie (FiLH) wrote:
patpro ~ patrick proniewski <patpro@boleskine.patpro.net> wrote:
In article <1heq8e8.1c9r0rklpmlarN%filh@filh.orgie>,
filh@filh.orgie (FiLH) wrote:
j'éteins systématiquement le powerbook a chaque déplacement, donc
2 fois par jour.
Quel intérêt ? J'ai 29 jours d'uptime sur un mac qui fait le même
trajet.
bah, c'est aussi simple de l'éteindre. :)
Ben... rebooter relancer 10 programmes, reprendre certaines visites de
site où j'en été, retapper 15 password, retrouver la musique que
j'écoutais, recharger le fichiers dans l'éditeur...
Bref 5 minutes de perdues et plein de fils de travail...
chez moi je bosse surtout sur le G5, alors fermer les fichiers sur le
powerbook, les rouvrir sur le G5, tout ca tout ca... casse couille :)
En plus l'environnement physique est pas le meme. Au taff je suis en bi
écran pour le portable, à la maison j'ai que l'écran intégrer : faut
faire le ménage dans les fenêtres.
Quel bazard...
Au boulot j'ai une sun, le mac sert... à des choses diverses et annexes.
À la maison c'est ma machine perso.
Donc en fait je fais souvent des choses le soir chez moi que je laisse
ouvertes au boulot sans y toucher.
Bon on va se boire un bibine ?
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
In article <1heq8e8.1c9r0rklpmlarN%, (FiLH) wrote:
j'éteins systématiquement le powerbook a chaque déplacement, donc 2 fois par jour.
Quel intérêt ? J'ai 29 jours d'uptime sur un mac qui fait le même trajet.
bah, c'est aussi simple de l'éteindre. :)
Ben... rebooter relancer 10 programmes, reprendre certaines visites de site où j'en été, retapper 15 password, retrouver la musique que j'écoutais, recharger le fichiers dans l'éditeur...
Bref 5 minutes de perdues et plein de fils de travail...
chez moi je bosse surtout sur le G5, alors fermer les fichiers sur le powerbook, les rouvrir sur le G5, tout ca tout ca... casse couille :) En plus l'environnement physique est pas le meme. Au taff je suis en bi écran pour le portable, à la maison j'ai que l'écran intégrer : faut faire le ménage dans les fenêtres.
Quel bazard...
Au boulot j'ai une sun, le mac sert... à des choses diverses et annexes. À la maison c'est ma machine perso. Donc en fait je fais souvent des choses le soir chez moi que je laisse ouvertes au boulot sans y toucher. Bon on va se boire un bibine ? 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 <1heqbfl.junexl1jagtdwN%, (FiLH) wrote:
Quel bazard...
oué :)
Bon on va se boire un bibine ?
ayé, j'ai bu la mienne, c'est sûrement pour ça que mes items launchd fonctionnent (presque).
patpro
In article <1heqbfl.junexl1jagtdwN%filh@filh.orgie>,
filh@filh.orgie (FiLH) wrote:
Quel bazard...
oué :)
Bon on va se boire un bibine ?
ayé, j'ai bu la mienne, c'est sûrement pour ça que mes items launchd
fonctionnent (presque).
In article <1heqbfl.junexl1jagtdwN%, (FiLH) wrote:
Quel bazard...
oué :)
Bon on va se boire un bibine ?
ayé, j'ai bu la mienne, c'est sûrement pour ça que mes items launchd fonctionnent (presque).
patpro
filh
patpro ~ Patrick Proniewski wrote:
In article <1heqbfl.junexl1jagtdwN%, (FiLH) wrote:
Quel bazard...
oué :)
Bon on va se boire un bibine ?
ayé, j'ai bu la mienne, c'est sûrement pour ça que mes items launchd fonctionnent (presque).
Ben moi aussi... :) (la bibine pas les launchd)
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:
In article <1heqbfl.junexl1jagtdwN%filh@filh.orgie>,
filh@filh.orgie (FiLH) wrote:
Quel bazard...
oué :)
Bon on va se boire un bibine ?
ayé, j'ai bu la mienne, c'est sûrement pour ça que mes items launchd
fonctionnent (presque).
Ben moi aussi... :) (la bibine pas les launchd)
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
In article <1heqbfl.junexl1jagtdwN%, (FiLH) wrote:
Quel bazard...
oué :)
Bon on va se boire un bibine ?
ayé, j'ai bu la mienne, c'est sûrement pour ça que mes items launchd fonctionnent (presque).
Ben moi aussi... :) (la bibine pas les launchd)
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
laurent.pertois
patpro ~ patrick proniewski wrote:
bon, c'est mon tout premier item launchd, donc il est peut etre blindé de bourdes, mais il fonctionne pas du tout :))
Lingon est ton ami de maintenant et de l'avenir :)
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
patpro ~ patrick proniewski <patpro@boleskine.patpro.net> wrote:
bon, c'est mon tout premier item launchd, donc il est peut etre blindé
de bourdes, mais il fonctionne pas du tout :))
Lingon est ton ami de maintenant et de l'avenir :)
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
bon, c'est mon tout premier item launchd, donc il est peut etre blindé de bourdes, mais il fonctionne pas du tout :))
Lingon est ton ami de maintenant et de l'avenir :)
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
patpro ~ patrick proniewski
In article <1heuded.wiuwkjluhf7tN%, (Laurent Pertois) wrote:
patpro ~ patrick proniewski wrote:
bon, c'est mon tout premier item launchd, donc il est peut etre blindé de bourdes, mais il fonctionne pas du tout :))
Lingon est ton ami de maintenant et de l'avenir :)
mouais... j'en doute :) il fonctionne maintenant mon launchd bidule, mais pas comme il faudrait, et j'ai dans l'idée que c'est un défaut/bug inhérent à launchd... J'ai une "race condition" entre le moment ou la requete de création du tunnel "on demand" est faite, et le moment ou le tunnel est dispo, et lanchdproxy ne transmet pas les paquets reçus avant établissement complet du tunnel au-dit tunnel une fois qu'il est connecté au deux bouts.
Bref, je pense que ce que je veux faire avec launchd n'est pas possible simplement. Y'a un type qui a fait des tunnels ssh "on demand", mais il ne procède pas comme moi, il ne crée pas un vrai tunnel, il ruse.
In article <1heuded.wiuwkjluhf7tN%laurent.pertois@alussinan.org>,
laurent.pertois@alussinan.org (Laurent Pertois) wrote:
patpro ~ patrick proniewski <patpro@boleskine.patpro.net> wrote:
bon, c'est mon tout premier item launchd, donc il est peut etre blindé
de bourdes, mais il fonctionne pas du tout :))
Lingon est ton ami de maintenant et de l'avenir :)
mouais... j'en doute :)
il fonctionne maintenant mon launchd bidule, mais pas comme il faudrait,
et j'ai dans l'idée que c'est un défaut/bug inhérent à launchd...
J'ai une "race condition" entre le moment ou la requete de création du
tunnel "on demand" est faite, et le moment ou le tunnel est dispo, et
lanchdproxy ne transmet pas les paquets reçus avant établissement
complet du tunnel au-dit tunnel une fois qu'il est connecté au deux
bouts.
Bref, je pense que ce que je veux faire avec launchd n'est pas possible
simplement.
Y'a un type qui a fait des tunnels ssh "on demand", mais il ne procède
pas comme moi, il ne crée pas un vrai tunnel, il ruse.
In article <1heuded.wiuwkjluhf7tN%, (Laurent Pertois) wrote:
patpro ~ patrick proniewski wrote:
bon, c'est mon tout premier item launchd, donc il est peut etre blindé de bourdes, mais il fonctionne pas du tout :))
Lingon est ton ami de maintenant et de l'avenir :)
mouais... j'en doute :) il fonctionne maintenant mon launchd bidule, mais pas comme il faudrait, et j'ai dans l'idée que c'est un défaut/bug inhérent à launchd... J'ai une "race condition" entre le moment ou la requete de création du tunnel "on demand" est faite, et le moment ou le tunnel est dispo, et lanchdproxy ne transmet pas les paquets reçus avant établissement complet du tunnel au-dit tunnel une fois qu'il est connecté au deux bouts.
Bref, je pense que ce que je veux faire avec launchd n'est pas possible simplement. Y'a un type qui a fait des tunnels ssh "on demand", mais il ne procède pas comme moi, il ne crée pas un vrai tunnel, il ruse.
In article <1heuded.wiuwkjluhf7tN%, (Laurent Pertois) wrote:
patpro ~ patrick proniewski wrote:
bon, c'est mon tout premier item launchd, donc il est peut etre blindé de bourdes, mais il fonctionne pas du tout :))
Lingon est ton ami de maintenant et de l'avenir :)
mouais... j'en doute :) il fonctionne maintenant mon launchd bidule, mais pas comme il faudrait, et j'ai dans l'idée que c'est un défaut/bug inhérent à launchd... J'ai une "race condition" entre le moment ou la requete de création du tunnel "on demand" est faite, et le moment ou le tunnel est dispo, et
Heu je débarque là... ce que tu fais c'est ce qui se faisait avec inetd ? En gros launchd écoute sur un port et quand on ouvre le socket alors il lance une appli derrière ?
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 <1heuded.wiuwkjluhf7tN%laurent.pertois@alussinan.org>,
laurent.pertois@alussinan.org (Laurent Pertois) wrote:
patpro ~ patrick proniewski <patpro@boleskine.patpro.net> wrote:
bon, c'est mon tout premier item launchd, donc il est peut etre blindé
de bourdes, mais il fonctionne pas du tout :))
Lingon est ton ami de maintenant et de l'avenir :)
mouais... j'en doute :)
il fonctionne maintenant mon launchd bidule, mais pas comme il faudrait,
et j'ai dans l'idée que c'est un défaut/bug inhérent à launchd...
J'ai une "race condition" entre le moment ou la requete de création du
tunnel "on demand" est faite, et le moment ou le tunnel est dispo, et
Heu je débarque là... ce que tu fais c'est ce qui se faisait avec
inetd ? En gros launchd écoute sur un port et quand on ouvre le socket
alors il lance une appli derrière ?
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/
In article <1heuded.wiuwkjluhf7tN%, (Laurent Pertois) wrote:
patpro ~ patrick proniewski wrote:
bon, c'est mon tout premier item launchd, donc il est peut etre blindé de bourdes, mais il fonctionne pas du tout :))
Lingon est ton ami de maintenant et de l'avenir :)
mouais... j'en doute :) il fonctionne maintenant mon launchd bidule, mais pas comme il faudrait, et j'ai dans l'idée que c'est un défaut/bug inhérent à launchd... J'ai une "race condition" entre le moment ou la requete de création du tunnel "on demand" est faite, et le moment ou le tunnel est dispo, et
Heu je débarque là... ce que tu fais c'est ce qui se faisait avec inetd ? En gros launchd écoute sur un port et quand on ouvre le socket alors il lance une appli derrière ?
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:
il fonctionne maintenant mon launchd bidule, mais pas comme il faudrait, et j'ai dans l'idée que c'est un défaut/bug inhérent à launchd... J'ai une "race condition" entre le moment ou la requete de création du tunnel "on demand" est faite, et le moment ou le tunnel est dispo, et
Heu je débarque là... ce que tu fais c'est ce qui se faisait avec inetd ? En gros launchd écoute sur un port et quand on ouvre le socket alors il lance une appli derrière ?
complètement. Ca fonctionne tout pareil, d'ailleurs c'est le mode "inetd compatible".
Le port local est "ouvert" en permanence (visible dans netstat par exemple), et c'est launchd qui reçoit la requête. Donc, mon appli se lance, elle fait sa requête sur le port local, launchd dit "il faut ouvrir le tunnel, viiiite !", mais c'est déjà trop tard, mon appli elle a déjà envoyé ses requêtes de connexion. Et ce con de launchproxy (qui ouvre le tunnel), il forwarde pas les requêtes lancées avant l'ouverture du tunnel. Donc mon appli elle attend (et elle timeout pas, c'est ça qui me surprend le plus). Finalement, je suis contraint de la relancer ou de lui faire refaire les requêtes de connexion. Le on demand c'est pas super au point ;)
patpro
In article <uxpsitueakwer@noorg.org>, FiLH <filh@filh.org> wrote:
il fonctionne maintenant mon launchd bidule, mais pas comme il faudrait,
et j'ai dans l'idée que c'est un défaut/bug inhérent à launchd...
J'ai une "race condition" entre le moment ou la requete de création du
tunnel "on demand" est faite, et le moment ou le tunnel est dispo, et
Heu je débarque là... ce que tu fais c'est ce qui se faisait avec
inetd ? En gros launchd écoute sur un port et quand on ouvre le socket
alors il lance une appli derrière ?
complètement. Ca fonctionne tout pareil, d'ailleurs c'est le mode "inetd
compatible".
Le port local est "ouvert" en permanence (visible dans netstat par
exemple), et c'est launchd qui reçoit la requête.
Donc, mon appli se lance, elle fait sa requête sur le port local,
launchd dit "il faut ouvrir le tunnel, viiiite !", mais c'est déjà trop
tard, mon appli elle a déjà envoyé ses requêtes de connexion. Et ce con
de launchproxy (qui ouvre le tunnel), il forwarde pas les requêtes
lancées avant l'ouverture du tunnel. Donc mon appli elle attend (et elle
timeout pas, c'est ça qui me surprend le plus).
Finalement, je suis contraint de la relancer ou de lui faire refaire les
requêtes de connexion.
Le on demand c'est pas super au point ;)
il fonctionne maintenant mon launchd bidule, mais pas comme il faudrait, et j'ai dans l'idée que c'est un défaut/bug inhérent à launchd... J'ai une "race condition" entre le moment ou la requete de création du tunnel "on demand" est faite, et le moment ou le tunnel est dispo, et
Heu je débarque là... ce que tu fais c'est ce qui se faisait avec inetd ? En gros launchd écoute sur un port et quand on ouvre le socket alors il lance une appli derrière ?
complètement. Ca fonctionne tout pareil, d'ailleurs c'est le mode "inetd compatible".
Le port local est "ouvert" en permanence (visible dans netstat par exemple), et c'est launchd qui reçoit la requête. Donc, mon appli se lance, elle fait sa requête sur le port local, launchd dit "il faut ouvrir le tunnel, viiiite !", mais c'est déjà trop tard, mon appli elle a déjà envoyé ses requêtes de connexion. Et ce con de launchproxy (qui ouvre le tunnel), il forwarde pas les requêtes lancées avant l'ouverture du tunnel. Donc mon appli elle attend (et elle timeout pas, c'est ça qui me surprend le plus). Finalement, je suis contraint de la relancer ou de lui faire refaire les requêtes de connexion. Le on demand c'est pas super au point ;)
patpro
FiLH
patpro ~ Patrick Proniewski writes:
In article , FiLH wrote:
il fonctionne maintenant mon launchd bidule, mais pas comme il faudrait, et j'ai dans l'idée que c'est un défaut/bug inhérent à launchd... J'ai une "race condition" entre le moment ou la requete de création du tunnel "on demand" est faite, et le moment ou le tunnel est dispo, et
Heu je débarque là... ce que tu fais c'est ce qui se faisait avec inetd ? En gros launchd écoute sur un port et quand on ouvre le socket alors il lance une appli derrière ?
complètement. Ca fonctionne tout pareil, d'ailleurs c'est le mode "inetd compatible".
Ok.
Le port local est "ouvert" en permanence (visible dans netstat par exemple), et c'est launchd qui reçoit la requête. Donc, mon appli se lance, elle fait sa requête sur le port local, launchd dit "il faut ouvrir le tunnel, viiiite !", mais c'est déjà trop tard, mon appli elle a déjà envoyé ses requêtes de connexion. Et ce con de launchproxy (qui ouvre le tunnel), il forwarde pas les requêtes lancées avant l'ouverture du tunnel. Donc mon appli elle attend (et elle timeout pas, c'est ça qui me surprend le plus). Finalement, je suis contraint de la relancer ou de lui faire refaire les requêtes de connexion. Le on demand c'est pas super au point ;)
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.
f.g.
-- 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 <uxpsitueakwer@noorg.org>, FiLH <filh@filh.org> wrote:
il fonctionne maintenant mon launchd bidule, mais pas comme il faudrait,
et j'ai dans l'idée que c'est un défaut/bug inhérent à launchd...
J'ai une "race condition" entre le moment ou la requete de création du
tunnel "on demand" est faite, et le moment ou le tunnel est dispo, et
Heu je débarque là... ce que tu fais c'est ce qui se faisait avec
inetd ? En gros launchd écoute sur un port et quand on ouvre le socket
alors il lance une appli derrière ?
complètement. Ca fonctionne tout pareil, d'ailleurs c'est le mode "inetd
compatible".
Ok.
Le port local est "ouvert" en permanence (visible dans netstat par
exemple), et c'est launchd qui reçoit la requête.
Donc, mon appli se lance, elle fait sa requête sur le port local,
launchd dit "il faut ouvrir le tunnel, viiiite !", mais c'est déjà trop
tard, mon appli elle a déjà envoyé ses requêtes de connexion. Et ce con
de launchproxy (qui ouvre le tunnel), il forwarde pas les requêtes
lancées avant l'ouverture du tunnel. Donc mon appli elle attend (et elle
timeout pas, c'est ça qui me surprend le plus).
Finalement, je suis contraint de la relancer ou de lui faire refaire les
requêtes de connexion.
Le on demand c'est pas super au point ;)
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.
f.g.
--
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/
il fonctionne maintenant mon launchd bidule, mais pas comme il faudrait, et j'ai dans l'idée que c'est un défaut/bug inhérent à launchd... J'ai une "race condition" entre le moment ou la requete de création du tunnel "on demand" est faite, et le moment ou le tunnel est dispo, et
Heu je débarque là... ce que tu fais c'est ce qui se faisait avec inetd ? En gros launchd écoute sur un port et quand on ouvre le socket alors il lance une appli derrière ?
complètement. Ca fonctionne tout pareil, d'ailleurs c'est le mode "inetd compatible".
Ok.
Le port local est "ouvert" en permanence (visible dans netstat par exemple), et c'est launchd qui reçoit la requête. Donc, mon appli se lance, elle fait sa requête sur le port local, launchd dit "il faut ouvrir le tunnel, viiiite !", mais c'est déjà trop tard, mon appli elle a déjà envoyé ses requêtes de connexion. Et ce con de launchproxy (qui ouvre le tunnel), il forwarde pas les requêtes lancées avant l'ouverture du tunnel. Donc mon appli elle attend (et elle timeout pas, c'est ça qui me surprend le plus). Finalement, je suis contraint de la relancer ou de lui faire refaire les requêtes de connexion. Le on demand c'est pas super au point ;)
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.
f.g.
-- 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:
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.
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 :)
patpro
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.
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 :)
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.
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 :)
