🚲 Tanguy Ortolo a écrit 12243 commentaires

Je ne vois pas le rapport, mais c'est quand même très amusant. Je prépare le pop-corn, on va bien rigoler.

Et même s'ils savaient, il faudrait qu'ils soient vraiment gonflés pour affirmer que libérer le code ça ralentit le développement. :-)

isohybrid ne suffit pas ! Il faut aussi que le système d'exploitation puisse aller chercher son système de fichiers sur une clef USB plutôt que sur un CD.

Moi, ce que j'adore, ce sont les services qui interdisent au contraire d'utiliser des caractères qui permettraient d'augmenter l'entropie.

Autrement dit, qui forcent à avoir un mot de passe faible. Du coup j'ai plusieurs classes de mots de passes :
– des mots de passes forts pour les services bien faits (avec des [:alnum:], des [.,;!:] et des [#&~*£$]) ;
– des mots de passes faibles pour les services mal fichus (avec des [:lower:] uniquement) ;
– un mot de passe merdique pour les services merdiques (avec quatre ou six [:digit:] uniquement).

Et ce qui est amusant, c'est que le mot de passe merdique en question, il ne me sert en pratique que pour deux services merdiques, les seuls que je connaisse, ceux qui au contraire mériteraient la plus grande sécurisation : ma carte bleue et le service d'administration de mes comptes en banques.

Bon, alors on va passer à la critique suivante : grâce à ce HTTP Digest, impossible d'intégrer une identification SIP à un système existant et unique comme PAM ou LDAP.

Vous ne seriez pas passés en GTK+2 par hasard ? Parce que la dernière fois que j'avais essayé Linphone, c'était juste abominablement moche en GTK+1, or là ça a l'air joli et intégré.

Le serveur gère l'authentification "http digest", votre mot de passe ne passera pas en clair sur le réseau.

Authentification DIGEST (votre mot de passe ne transite pas en clair sur le réseau) ;

… mais est stocké en clair sur le serveur. Avant qu'on ne me le rétorque, oui, je sais, pas la peine de stocker vraiment le message en clair, le hachage HA1 (oui, HA1, ce n'est pas un algorithme mais un nom de variable dans le protocole HTTP Digest) suffit, sauf que ce hachage HA1 suffit à se connecter, donc il remplace le mot de passe, donc le stocker en clair sur le serveur c'est comme stocker le mot de passe en clair, si quelqu'un récupère le fichier de mot de passe il peut se connecter. Donc je maintiens, le vrai mot de passe, c'est à dire ce qui suffit à se connecter, c'est à dire HA1, est stocké en clair sur le serveur.

Tout ça parce que l'équipe SIP à l'IETF a cru intelligent de déprécier HTTP Basic parce que « le mot de passe transite en clair sur le réseau et que c'est très mal », ce qui est vrai, sauf que SSL.

HTTP Basic seul : le mot de passe transite en clair mais n'a pas à être stocké en clair sur le serveur.
HTTP Basic + SSL = le mot de passe ne transite pas en clair et n'a pas à être stocké en clair sur le serveur.
HTTP Digest = le mot de passe ne transite pas en clair mais doit être stocké en clair sur le serveur.

"Les associations représentant les camionneurs, c'est-à-dire ceux qui occupent une place dominante et sans cesse croissante des autoroutes, prônent une neutralité totale vis-à-vis du trafic. Mais en cas de saturation, ce seront l'ensemble des utilisateurs qui ne pourront plus avancer, y compris les particuliers utilisant leurs voitures, y compris les ambulances nécessitant un trafic accéléré."

le ministre estime que les opérateurs doivent pouvoir disposer des capacités de "garantir une qualité de service minimale pour des services prioritaires", dont la téléphonie et la télévision sur IP.

Comparer la télévision aux ambulances, ben voyons…

Et de toute façon, la télévision et la téléphonie sur IP fournies par les opérateurs n'ont rien à voir avec Internet, ce sont des services gérés. Un opérateur peut bien tirer deux ou trois tuyaux séparés pour Internet, le téléphone et la télévision, ce n'est pas une atteinte à la neutralité d'Internet. Hop, fin de l'histoire, M. Besson est à côté de la plaque.

Et pourquoi ça s'appelle « on » et « off » à ton avis ?

Les fichiers de configuration ne sont pas dans /usr/share mais dans /etc. Ceux dans /usr/share sont fournis par les paquets, il ne faut pas les modifier parce que tes modifications seraient écrasées à la prochaine mise à jour.

En plus « on » et « off » ça désigne les positions physiques d'un bouton-poussoir. Lorsqu'il s'agit d'une glissière, ça ne convient plus.

Chez moi, ils annoncent 30 euros par mois de tarifs en promo bêta à 20 euros par mois.

Par ailleurs, dans la fiche technique ils parlent d'IPv6 /128 à venir. /128 : une seule adresse IPv6 ? C'est du foutage de gueule ça…

Ça m'étonne, parce que les Flash, je ne les lis pas. J'ai bien Gnash d'installé, mais il est configuré pour ne lancer les animations qu'à ma demande.

Comme mentionné plus haut par quelqu'un d'autre, mettre un disque dur et une flash en RAID 0 c'est bizarre.

Si ce que tu veux, c'est de la vitesse de chargement du système et des logiciels, et de la capacité de stockage pour tes documents, je te suggère plutôt :
– une flash et 10 Gio montée en /,
– un disque dur normal monté en /home.

Tu devrais mettre à jour tes connaissances de la FHS — filesystem hierarchy standard —. /mnt c'est pour les montages temporaires, depuis des années. /media/data serait plut approprié.

Et à part ça, « disque SSD » c'est une oxymore, il vaut mieux parler de périphériques SSD.

Eh bien si, justement, il y a des boutons pour arrêter la lecture, passer à la piste suivante… qui marchent très bien.

Désolé pour le ton du dernier paragraphe, je réponds juste à e qui me semblait être une sorte de sarcasme de la même façon.

Le streaming, c'est de la diffusion en continu, c'est à dire l'envoi de données multimédia au même rythme que le destinataire les lit. C'est un concept, pas une implémentation. Ses implémentations s'appellent par exemple HTTP et RTP.

Là, il s'agit d'un site web. Il est possible que l'envoi des musiques à écouter se fasse en continu forcé par le serveur, mais j'en doute. Il serait beaucoup plus simple pour eux de simplement servir les chansons en HTTP, comme le fait YouTube pour les vidéos, et de laisse le client les télécharger d'un coup ou au rythme qu'il veut.

Non, ma question ne portait pas sur le concept utilisé, qui n'est probablement pas de la diffusion continue, ni même sur le protocole utilisé, qui est très probablement du HTTP. Je m'interrogeais plutôt sur la façon dont cette diffusion était intégrée à leurs pages web.

Maintenant, vu que tu as l'air de ne rien y connaître du tout vu ta réponse tellement vague et improbable qu'elle en est à côté de la plaque, si tu as d'avantages d'infos, je t'écoute, sinon bonne nuit.

Je viens de redécouvrir Jamendo, là. Et c'est très curieux : alors que je ne lis pas le Flash, et que je ne vois aucune balise audio dans le code de leur page, ça lit la musique. Comment font-ils ? Je soupçonne que j'aie loupé une balise audio bien cachée, en fait.

L'élimination éventuelle de MPEG-4 AVC sur le web est presque exclusivement dans les mains de Google. Ce sont eux, youTube, le plus gros diffuseur de vidéos. Après avoir supprimé la prise en charge de MPEG-4 AVC de Chrome, ils peuvent retirer ce format de YouTube, s'ils veulent vraiment sa mort.

Ça ne se refuse pas, je ne suis pas sûr. Pour ce qu'elle vaut maintenant, la Légion d'honneur, avec des footeux et des chanteurs dedans… L'Ordre du mérite, je ne dis pas, mais la Légion d'honneur…

Ce n'est pas LibreOffice.org, abrégé LOo, mais LibreOffice tout court, abrégé LibO.

Ah oui, au temps pour moi.

ça va être génial lorsqu’il faudra acheter sa baguette de pain 0,000 000 000 003 bitcoins

Pas de souci, ce ne sera pas possible : la plus petite fraction de BitCoin est le dix-millionième. Avec 21 millions de BitCoins comme masse monétaire maximale, cela fait un maximum de 210 milliards d'atomes monétaires, ce qui me semble bien trop peu. Encore un argument contre ce système…

essaie de le brancher sur un baladeur Apple si tu passes devant un Apple Store

Il faut d'abord que je m'achète une perruque et des lunettes noires pour ne pas être reconnu en train d'aller dans un Apple Store alors.