🚲 Tanguy Ortolo a écrit 12334 commentaires

Non, tu confonds avec rxvt-unicode.

Comme ça le livre numérique, est aussi confortable que le livre papier.

Ou pas. Le livre papier est tranché net et relié, ce que je ne peux pas faire. Et puis je soupçonne qu'il coûte moins cher que l'impression que je pourrais moi-même effectuer avec mon imprimante laser.

Un coupon glissé dans le livre, avec une URL personnalisée.

Attention quand même : les paquets volatils, c'est officiel et pris en charge. Les paquets rétro-portés, non.

J'en déduis que l'auteur assume une partie des coûts de distribution, directement prélevée de ses revenus d'auteur, ces derniers étant supérieurs à 30% du prix de vente de l'oeuvre au format numérique, et 10% du pour le format papier.
Moi qui pensais que la distribution était entièrement à la charge de l'éditeur...

10% par-ci, 30% par là... Dans les fait, les revenus de l'auteur pour chaque oeuvre sont les mêmes non, c'est juste le prix de vente qui dépend du mode de diffusion ? Du coup, en quoi c'est plus "équitable" ?

Je n'ai rien compris à ces calculs.

Pour moi, le livre papier coûte cher à produire. Il est vendu un certain prix, qui inclut l'amortissement des frais fixes de production, le coût marginal de production, la TVA, la marge de l'éditeur et celle de l'auteur. Là-dessus, la marge de l'auteur correspond à 10%.

Quant au livre électronique, il coûte peu à produire. Il est vendu un certain prix — moins chez que le papier — qui inclut l'amortissement des frais fixes de production, le coût margina — presque nul — de production, la TVA, la marge de l'éditeur et celle de l'auteur. Là-dessus, la marge de l'auteur correspond à 30%. C'est supérieur aux 10% précédents, où est le problème ?

C'est très bien, ça ! Je leur souhaite que ça marche bien, et je les encouragerais bien en achetant, si je supportais de lire sur écran, ce qui n'est pas le cas. :-)

Le site de Bélial vient de se faire LinuxFriser ou je rêve ?

être plus firefall/proxy-friendly

Pas friendly. Au contraire, le but est de contourner les pare-feux.

Cependant il me semble que Mercurial est plus avancé dans la gestion des dépots via http/https : ça ressemble plus à SVN de ce côté.

Exact, mais qu'est-ce que ça apporte au juste ?

Git a deux modes de transmission principaux : la publication en lecture seule via son protocole natif, et l'envoi via SSH.

Avec git je ne pense pas qu'on puisse utiliser HTTP/HTTPS pour envoyer les modifs d'un dépot local vers un dépot distant (ou alors il y a une bidouille).

Si, ça se fait très bien, mais ce n'est pas super bien intégré. Le transport HTTP de Git est clairement un palliatif quand on ne peut utiliser ni le protocole natif, ni SSH.

Git a des interfaces graphiques. Personnellement, je ne m'en sers que de façon auxiliaire, pour visualiser l'historique de façon graphique, par exemple. J'aime bien gitg, dans le genre : [http://trac.novowork.com/gitg/].

Tu peux peut-être l'aider à implémenter STARTTLS. Genre, s'il utilise Postfix, c'est une ligne très simple à ajouter dans le master.cf.

Ah, le serveur n'est pas à toi, c'est pour ça ! Je n'avais pas compris ça, désolé.

Oui, certes, quand on ne contrôle pas le serveur, à part formuler une demande à son administrateur, on ne peut pas grand chose d'autre que s'adapter, évidemment.

C'est port 25.

Pour la transmission de courrier inter-serveurs, oui. Pour la soumission de courrier de client à relais, non, c'est le port TCP 587.

Je ne sais pas dans quel monde tu vis, moi je vis dans le monde réel avec le port 25 (relativement) souvent bloqué, et pas le 465.

Moi je vis dans le monde réel avec le port TCP 25 (relativement) souvent bloqué, et pas le TCP 587.

Je me retrouve avec à priori la même chose que sur le port 25, donc pas de STARTTLS, donc communication en claire, heu...

Gné ? C'est toi qui décide de faire ou non du STARTTLS.

Non, c'est une entreprise, qui, à la différence des autres, est plutôt dans l'esprit d'Internet. Dynamique et intéressée à la technologie.

perso je n'ai jamais eu aucun problème avec le port 465 (SMTPS)

SMTP over SSL ne devrait plus être utilisé ! Depuis, on a intégré TLS à SMTP, avec STARTTLS !

Et le 465 ne devrait pas être utilisé pour cela : il pourrait très bien être bloqué, vu qu'il sert aussi et avant tout à l'envoi normal de courrier inter-serveurs, juste en mode sécurisé.

Pour la soumission de courrier à un serveur relais, il y a le port de soumission (TCP 587). Lui ne devrait jamais être bloqué, et n'a aucune raison de l'être.

Oui, Google sont un cas à part. :-)

Et si c'était un protocole standard publié par l'IETF, genre ?

Ah, c'est possible. Les grands opérateurs, et, d'une façon générale, les professionnels, par opposition aux amateurs, sont limités par leur inertie et leur recherche de rentabilité.

Donc ce genre de services modernes (DKIM, soumission SMTP chiffrée et identifiée, IPv6), ne l'attendez par trop chez les pro : c'est surtout déployé chez les amateurs.

Quand MSN change subrepticement son protocole pour faire chier les clients alternatifs, il faut pouvoir réagir rapidement, et mettre à jour rapidement.

Il faudrait surtout se libérer de la dépendance intégrale à une société qui fait ce qu'elle veut de son service.

Et ce n'est pas un problème de sécurité, donc il faut bien au moins les backports.

Non, les volatils. [http://volatile.debian.org/].

Mais je l'implémente ! Et puis TSIG pour les transferts de zone DNS sécurisés.

Paypal et ebay l'implémentent

Moi aussi je l'implémente. :-)

et le webmail gmail le vérifie

Et moi aussi je le vérifie. Ah, et puis Yahoo! aussi.

Chez laposte.net c'est plus récent : puisque le serveur SMTP utilise le port 25, bloqué par beaucoup de FAI par défaut, laposte.net conseille l'utilisation du serveur SMTP de son fournisseur d'accès pour envoyer des e-mails.

Depuis, on a inventé le port de soumission de courrier (TCP 587), qui sert précisément à contacter un relais de courrier. Avec pour contrainte que celui-ci devrait vérifier l'identité de celui qui soumet le courrier, soit par adresse dans le cas d'un réseau interne, soit pas identifiant et mot de passe, le tout sur connexion chiffrée.

Mais bon, c'est la Poste, donc connexion chiffrée, il ne faut pas trop leur en demander, quand même.

Le but est de sortir la nouvelle stable à date fixe

N'importe quoi. Il n'a jamais été question de sortir Debian à date fixe.

Et 7 mois c'est rien au niveau de l'informatique qui n'a plus évolué depuis l'invention du HTTP, le protocole universel.

Tout ce message est du second degré ?

Ah, au temps pour moi, pour l'édition 2010, il n'y a pas 6 pages de résultats, mais plutôt zéro résultats. Bon, je suppose qu'ils travaillent dessus, donc on va attendre un peu.

N'empêche qu'une page officielle, plus accessible que la fonction de recherche de FreeTorrent, ne serait pas un luxe.

Parce que, devoir rechercher soi-même sur FreeTorrent, puis se payer 25 pages des listes de 8 éléments, c'est juste inutilisable.