🚲 Tanguy Ortolo a écrit 12224 commentaires

Bon, ce n'est pas un ssh, non plus, hein.

J’installe le gestionnaire de téléchargement parce que ça a l’air plus pratique et je valide (mais je dois pouvoir télécharger individuellement les chansons sans l’installer à priori). C’est un plugin firefox, donc je redémarre firefox et je cliquer sur Télécharger.

Message à destination d'Amazon : man tar zip.

Et la marge, elle, explose. De la vente de musique en ligne, c'est un coût marginal de production pratiquement nul.

C'est un synonyme de bronsonisation, je crois.

C'est un projet GNU ? Je ne vois pas de référence à ce sujet sur le site Web, ce serait peut-être une bonne idée d'en parler.

le jeu est vendu sur l'Apple Store, j'imagine que c'est plus pratique pour les utilisateurs d'iPhone de l'acheter que de se le compiler

Oh, c'est encore plus simple, à vrai dire : les restrictions techniques imposées par Apple interdisent d'exécuter sur un iPhone du code qui n'a pas été signé par Apple. Donc les compilations personnelles ne peuvent pas être lancées.

C'est quoi ces « contraintes du streaming » ?

Du vrai streaming, ça peut imposer un débit constant, par exemple. Ça ne concerne pas YouTube qui est un site de téléchargement de vidéos et non de streaming. Alors je ne vois pas.

Le seul test "Get the facts" qui met Theora en avant est biaisé (Distance entre les Keyframes énorme, inexploitable pour du streaming où on veut faire des "seek", et ce paramètre change énormément la qualité d'une vidéo)

Il a surtout été vérifié que la compression utilisée par YouTube est inférieure, à qualité égale, à celle produite par le codec Theora actuel.

giggle, gitg ?

Personnellement, j'utilise surtout la ligne de commande, et parfois des outils graphiques quand ça apporte quelque chose, par exemple pour afficher l'arbre des commits ou ajouter des changements individuels plutôt que par fichier entier.

Non. Envoyer des données avant d'avoir la réponse au EHLO, c'est une erreur. Aucune implémentation correcte de SMTP ne le fait.

Ça ne bloque aucune implémentation normale de SMTP.

Tout à fait d'accord, je signalais juste que l'argument « écologie » pour ne pas avoir son serveur chez soi, c'est juste débile aussi.

Où, au juste, expose-t-il des méthodes avec des faux positifs ?

alors deja un serveur qui consomme 10 watts en pleine charge, j'aimerais bien voir ca.

http://www.fit-pc.com/

Chauffer sa maison avec 5W, pareil, je rigole un grand coup la.
Si t'arrives a rechauffer tes pieds dans un studio de 9m2 c'est deja le bout du monde.
Autant chauffer son salon avec briquet a ce compte la, ca chauffera pas plus mais au moins ca eclairera...

Mais je ne prétends pas que ça suffit à chauffer la maison ! Simplement que, l'hiver, 100% de l'énergie consommée par un serveur perso chez soi est utile au chauffage de la maison. Autrement dit, que 0% de l'énergie est perdue.

Encore une fois, il y a au moins un mec qui s'y connaît, qui reçoit la plus grande quantité de spams enregistrée pour une personne (un million par jour), et qui a mis au point ce qu'il faut pour trier avec une efficacité redoutable sans le moindre faux positif.

http://acme.com/mail_filtering/

aaaaah l'écologie : c'est plus écolo d'avoir une machine up 24/24 chez toi que d'utiliser le smtp de ton fai ?

10 Watts dont 100% utilisés pour la puissance pure ton serveur personnel, et dont 100% contribuent au chauffage de ta maison l'hiver. Donc, 50% du temps seulement, c'est 10 Watts consommés en perte.

À comparer avec la consommation des serveurs du FAI, donc je pense au moins 25% sert à l'évacuation de la chaleur produite, même en hiver, chaleur qui n'est pas réutilisée. Plus la consommation des routeurs et autres équipements réseau associés.

Les commentaires partent un peu dans tous les sens à propos de noms DNS inverses. Je rappelle donc, que ce qui est important, c'est d'avoir un nom DNS inverse associé à son adresse IP, et que l'enregistrement A ou AAAA associé à ce nom donne bien la même adresse IP.

Avec un nom DNS inverse qui correspond au nom de domaine donné par son serveur (EHLO), c'est purement cosmétique. Refuser un message parce qu'il ne correspond pas est explicitement interdit par la RFC SMTP : [http://tools.ietf.org/html/rfc5321#section-4.1.4].

Avoir un nom DNS inverse qui, privé de son premier composant, correspond au nom de domaine de l'expéditeur du message (MAIL FROM:), c'est juste cosmétique. Aucun serveur sérieux ne refusera du courrier parce que ça ne correspond pas.

Enfin, toujours d'après la RFC SMTP, quand on n'a pas de nom d'hôte, par exemple quand on n'a qu'une adresse dynamique, il faut utiliser une adresse électronique comme EHLO !

Au risque de me répéter, tu peux conserver ton serveur de courrier en lui faisant utiliser le relais du FAI pour sortir. C'est moins bien que d'être complètement indépendant, mais mieux que rien tout de même.

Pour des moyens sérieux et sans faux positifs : http://acme.com/mail_filtering/ .

On peut avoir d'excellentes raisons de vouloir envoyer son courrier directement. Par exemple, pour régler une politique SPF stricte : autoriser l'envoi avec <@example.com> exclusivement depuis son adresse IP, plutôt que depuis celle de mon serveur relais utilisé par tous les clients de mon FAI.

Pourquoi le moinsser ?

À l'affirmation
je ne connais aucun FAI grand public qui le permet

la réponse
et si, free le fait...

est un contre-exemple tout à fait pertinent !

Avec des arguments pareils, autant tous nous vendre à Google pour tous nos services.

Ça, pour le coup, refuser du courrier parce que le nom DNS inverse ne correspond pas, c'est explicitement interdit par la RFC. Et ce n'est pas une mesure anti-spam efficace.

Pour SPF, il serait plus intelligent d'autoriser juste la plage d'adresses dynamiques dans laquelle tu es. Celle attribuée à ton DSLAM, quoi.

http://acme.com/mail_filtering/