Larry Cow a écrit 5011 commentaires

La citation en question est plus de la forme "je ne suis pas d'accord avec vos idées, mais je me battrais pour que vous puissiez les exprimer". C'est généralement attribué à Voltaire.

Si c'est possible pour un forummaster, c'est possible pour un individu lambda, et c'est la porte ouverte à plein d'abus. Que ce soit plus simple pour l'utilisateur de base, c'est évident, mais c'est aussi plus simple si Outlook exécute automatiquement tous les .exe qu'il reçoit par mail, si tu vois ce que je veux dire.

Une personne ne peux connaître ta disponibilité Jabber que de deux manières: soit en te le demandant, soit en ayant la permission de le faire sans te demander (i.e. en étant admin de ton serveur). C'est tout.

Sans ce mécanisme, n'importe qui peut obtenir une information que tu ne tiens pas à diffuser (et même l'utilisateur lambda ne tient pas à la diffuser, il suffit de voir l'usage frénétique de la fonctionnalité de "blocage" de MSN Messenger).

En bref: ce que tu demandes de faire n'est pas possible, à moins que l'administrateur du forum soit aussi l'administrateur du serveur jabber de ses utilisateurs. Après, on peut envisager un comportement coté client qui autorise automatiquement les JID sous forme de "presencebot@server.tld", mais c'est risquer qu'un mec collecte les disponibilités avec son propre serveur.

D'un plancher, pas d'un parquet. Contrairement à ce que tu disais plus haut.

Enfin à la limite, on s'en balance.

Pas beau? Les clients jabber?

Tu a regardé Gush? Certes, il est pas libre et en outre s'appuie sur une technologie notablement non-libre (flash), mais bon...

Gush: http://www.2entwine.com/(...)

D'après les équations, le système chat/tartine/beurre devrait entrer dans un état indéfini. Concrètement, on assiste à une mise en lévitation du système le temps que l'état se définisse.

I would appreciate alternatives, but clients must be GPL'ed or they must have a commercial Brutus license. I really don't see any other realistic choices than Evolution, considering the available GPL'ed groupware products, but I am always open for suggestions.

Isn't there some GPLed groupware product from KDE guys?

En fait, une telle solution serait extrèmement intéressante uniquement si le support suit au niveau client. Et une telle chose aurait nettement plus de chances de pouvoir arriver si Brutus savait interfacer d'autres types d'architecture qu'Exchange: postfix, OpenGroupware, Kolab, ...

Une telle chose serait-elle prévue?

English version for colding:

That kind of solution would be very very interesting, but only if there is some good support from the client side. And such a thing would be eased if there were other architectures supported by Brutus, as postfix, OpenGroupware, Kolab, ...

Is it planned?

Si j'ai proposé ça, c'est que s'il recherchait le logiciel et qu'il l'a pas retrouvé, j'ai supposé que c'était probablement parce qu'il n'existait plus.

C'est ce que j'avais supposé aussi, à tort manifestement (et heureusement). Et non, le recoder n'était pas du tout à l'ordre du jour, fut-ce en cinquante lignes: le but initial était de faire marrer un collège fan de ce genre de choses. Rien d'essentiel, donc.

Et sinon, ça s'appelle pas des stéréogrammes, mais des autostéréogrammes.

Si je ne m'abuse, l'ensemble des seconds est inclus dans le premier ensemble. Donc bon, pour imprécis, ça n'en était pas moins vrai (cela dit, j'ai bel et bien merdé)

En espérant que ça t'aide.

Ouiiiiiiiiiiiiiii! Complètement, c'est lui que je cherchais. Je sais pas pourquoi, j'ai omis de regarder du coté de aalib, pour moi c'était un truc obscur hébergé chez Lycos. C'était tellement simple que je suis passé à coté ;)

Et pour le titre de ma question, c'était volontaire (ce qui ne signifie pas que c'était judicieux): si le résultat est un stéréogramme, l'outil qui le construit est un stéréo...graphe :)

(enfin sur le moment, ça me semblait évident, mais il était tard)

J'avais regardé Brutus à l'époque de l'annonce, et il m'avait semblé qu'il y avait une grosse limitation par rapports aux connecteurs existants: il nécessite de s'installer en tant que serveur. Il ne s'agit pas, toujours si j'ai bien compris, d'un module client permettant de parler à Exchange, mais d'un module serveur permettant à des clients (éventuellement avec une surcouche en plus à ce niveau) de parler à Exchange.

Autant ça peut être très pratique pour une entreprise qui voudrait migrer la moitié de son parc sous linux tout en conservant Exchange, autant ça ne sert à rien à:
- l'employé qui fait tourner _sa_ machine sous Linux malgré des collègues massivement sous Windows.
- l'entreprise qui migre en commençant par les serveurs.

Cela dit, ça peut avoir son intérêt, et je peux également avoir mal lu.

Pas mal du tout. Reste plus qu'à trouver la même en 2 ports. :)

Plus récent, mais prometteur: http://www.positro.net/trigger/(...)

Et les contributions (en cours) à gcc.

Tiens d'ailleurs, on a réussi à capturer Saddam.

(je sors)

Bien entendu, tu as "l'accord express de Reuters", n'est-il pas? Autrement, ta missive serait "rigoureusement interdite".

(je sors)

C'est un style différent, mais c'est un bon début je trouve. Franchement, même si le style "dessin" originel est sympa, je trouve ta version fort agréable à l'oeil. Tu en as parlé aux développeurs "officiels"? ;)

Arrh, j'étais persuadé de l'avoir, en plus, ce paramêtre à la con. Complètement merci, tu me sors de trois jours de galères :)

C'est mieux (je peux me connecter avec le couple 'guest'/''), mais il n'y a toujours pas moyen d'avoir accès au volume sans couple login/pass. Je me demande, en fait, si cette fonctionnalité existe dans samba: si ça se trouve je me fatigue pour rien ;)

Complètement hors-sujet, mais si je ne m'abuse "proxy" et "proximité" n'ont qu'un lien très lointain (et encore). En effet, "proxy" en anglais signifie grosso-modo "intermédiaire" (on retrouverait la racine dans "proxénète" en français).

Si quelqu'un voit le lien avec "proximité", d'ailleurs, ça m'intéresse.

C'est ce que j'essayais de faire, mais ça ne marche pas. smbclient accepte bien de se connecter sans mot de passe, mais il en demande un quand même.

Depuis un poste windows, c'est pire: il demande un couple user/password, et n'en accepte aucun.

Je précise un peu: je cherche à obtenir une situation dans laquelle le serveur ne demande aucun mot de passe, même vide, au client.

Je dis surement une bétise, mais c'est pas le boulot de procmail, ça?

Si la machine est eteinte que se passe t il?

Quand un serveur de mail veut t'envoyer un mail (à toi@tonserveur.org, par exemple), il demande au DNS la valeur du champ MX (Mail eXchanger) de tonserveur.org. Théoriquement, celui-ci contient l'adresse IP de ton serveur mail. L'émetteur va donc tenter une connexion sur ton port 25, et t'envoyer le mail.

Maintenant, si ta machine est éteinte, ou de manière générale indisponible, l'émetteur va arriver sur ton port 25 et... rien. Il ne transmettra donc pas le mail. Il existe plus que certainement des serveurs qui retentent l'émission plusieurs fois en cas d'erreur, mais rien ne peut te garantir que:
- tous les émetteurs se comporteront de cette manière,
- par manque de bol, l'émetteur ne réessaye qu'à des moments ou tu es hors-ligne (en général, l'intervalle entre deux tentatives augmente avec le temps).

La seule solution vraiment viable à ce problème est la suivante: le DNS spécifie non pas un enregistrement MX, mais une liste ordonnée. Lorsque que le premier MX est indisponible, l'émetteur va essayer le suivant, jusqu'à en trouver un disponible. On parle donc de "MX secondaires" ou "MX backup".

Ces MX de rechange vont conserver dans leur file d'attente les mails qui sont destinés à ton serveur, et vont réessayer régulièrement de lui transmettre. Ainsi, un temps t(proportionnel à la durée de ton absence) après ton retour sur le net, tes mails te seront délivrés, comme si de rien n'était.

Dans la pratique, la solution la plus souple consiste à se mettre d'accord avec une paire de copains (de préférence géographiquement éloignés et chez des FAI différents) utilisant également leurs propres serveurs de messagerie pour se "couvrir" mutuellement. Sinon, certains FAI (nerim, si j'ai bonne mémoire) proposaient de faire office de MX secondaire. Dyndns aussi, mais je me souviens plus du tarif.

courrier-imap fait les 2 mais j'ai entendu dire qu'il etait pas trop bien en imap

Plus exactement, Courier fait les deux (via courier-imapd et courier-popd), et bien d'autres choses (imap over ssl, pop over ssl, etc.).

Je l'utilise depuis plusieurs années, en tant que serveur imap, et j'en suis très content. Tu pourrais détailler ce qui te dérange chez lui?

Ca a l'air sympa (je garde dans un coin, merci bien), mais même reproche qu'à Bayonne: c'est gros, ça fait plein de choses, on sait pas forcément trop lesquelles à première vue.

Ce que je cherche à faire est extrèmement ciblé, et gagnerait à être intégré directement dans mon application.

Enfin je vais expérimenter un peu avec les modems RTC, et je verrais bien si je trouve la commande magique qui permet d'obtenir ça. Sinon, ben Poudre Verte (c)(tm), bien entendu ;)

Dans un premier temps, je te conseille la lecture des Wine Weekly News, sur le site de Wine. Il y a assez régulièrement des informations sur les entrailles de Wine, ainsi que sur les méthodes de débug. J'ai vu passer récemment (c'est pour ça que je t'en parles) un article sur l'art et la manière de sortir un report de bug propre d'un crash Wine. Si je le retrouve, je te le ferais savoir.