La plupart des musiciens ne lisent pas les petites lignes du contrat qui les lie à la sacem et diffusent certaines de leurs compositions sous licence libre.
Je me demande si l'incapacité à lire n'est pas le plus grand mal de notre société. Musiciens qui signent des contrats sans les lire. Utilisateur qui acceptent des licences sans les lire. Électeurs qui votent pour des programmes sans les lire.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
Je trouve ça super simpliste cette idée d'objet qu'on imprime à la maison, exprimée ainsi.
Par "définition", un objet qu'on peut fabriquer avec une imprimante 3D est fabriqué déjà de façon entièrement automatisée, avec une poignée de gus à peu près diplômés qui surveillent une machine sophistiquée qui chie des millions de pièces par jour.
Ça serait plutôt au niveau de l'assemblage de certains trucs qu'il faut de la main d'oeuvre. Et là, l'imprimante 3D peut apporter quelque chose. Pas pour fabriquer la pièce, mais parce que l'entreprise qui fabrique la pièce et fait travailler des chinois pour l'assembler refusera de te vendre la pièce afin que tu l'assembles toi-même.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
Oui mais Akonadi c'est pour KDE uniquement. Donc ça pue. J'utilise KDE, mais je n'aime pas cette fragmentation des bureaux Linux. Au contraire ça serait beau d'avoir des solutions capables d'être adoptées sur d'autres OS, et d'être non-indispensables pour les OS qui n'en veulent pas.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
Ce qui m'ennuie, c'est que j'utilise parfois des applis KDE, parfois des applis Gnome, et Kwallet semble mal gérer les deux (Et non, KDE ne propose pas de remplaçant sérieux à Gajim).
Et puis ça serait bien d'avoir un truc qui "tout intègre", y compris par exemple les mots de passe stockés par Firefox (bon, là c'est plutôt à Firefox de tendre la main). Personnellement j'utilise Keepassx, qui permet également de stocker les mots de passe des serveurs SSH (y compris ceux où je ne peux pas "poser" ma clef publique), les services Web sensibles que je ne veux pas sauver dans le navigateur (type banque, administrations..)
Forcément, ça fait du copier/coller à la main. Mais ça serait bien d'avoir quelque chose de réellement unifié, capable de fournir automatiquement le bon mot de passe à Konqueror, à Gajim, au client SSH lancé depuis bash dans Konsole, à Firefox.. Oui, j'en demande beaucoup :)
Et, si possible, sans casser l'existant, c'est à dire sans compliquer la vie de l'utilisateur qui ne veut pas profiter de ces fonctionnalités.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
Aaah là je saisis, merci ! Un exemple, ça permet d'afficher sur le client de messagerie le nom de la chanson qu'on écoute, si on le souhaite. Je vois mieux :)
Bon ben vive DBUS alors.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
qui communiquent éventuellement en écrivant dans des fichiers.
Euh, pas vraiment non... T'imagines le bordel ? Pour cela, on a inventé les IPCs...
Je voulais dire, par exemple : l'application mail reçoit un fichier .ics, elle le stocke dans /tmp, l'application agenda l'y trouve. C'est comme ça que ça a l'air de marcher..
J'ai regardé du côté des "Linux Interprocess Communications" (c'est plus facile à chercher ainsi) et effectivement ça répond mieux aux besoins. T'as un exemple d'utilisation concrète dans un environnement de bureau ?
Je pense que tu mélanges un peut tout, là on parle d'un pont entre les applications(qui exposent leur fonctionnalités via dbus) et le bureau... En fait, libunity et dockmanager permettent à chaque bureau d'en faire ce qu'il veut...
Oui, c'est fort probable que je mélange. C'est un point que j'ai toujours trouvé obscur sous Linux. Donc, le standard c'est dbus, et une application peut par exemple demander via dbus la liste des contacts de l'utilisateur, ou bien le nom du serveur SMTP disponible sur le réseau ?
(Je comprends pas pourquoi je me fais moinsser en posant la question. J'ai juste du mal à comprendre comment ces trucs fonctionnent, ce qu'ils apportent. C'est humain non ? Si quelqu'un a une doc qui explique tout ça sans balancer deux sigles par phrase je suis preneur aussi )
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
J'avoue ne pas comprendre grand chose à ces concepts, à ces daemon et ces intégrations d'environnement de bureau. À mes yeux, "le bureau" c'est un gestionnaire de fenêtre, des barres de menus, des applications qui communiquent éventuellement en écrivant dans des fichiers.
Et je me sens de plus en plus paumé quand je vois de l' "intégration". Par exemple le truc KDE qui me dit "telle application veut accéder au trousseau de clef, veuillez choisir un mot de passe principal".. heu, what, wait ?
En soi je n'ai rien contre ce concept d'une "intégration" des applications. Je pense saisir l'idée : avoir des ressources globales (des contacts, des mails, un agenda), et permettre à chaque application de travailler avec et de notifier les autres (je reçois un mail avec un .ics => j'ajoute le RDV dans mon agenda d'un clic, sans manipuler le .ics moi-même). C'est à peu près ça ?
Concrètement, il y a un standard unique qui se dessine ? Les applications gèrent tout ça correctement ? Ça marche bien ? C'est compatible avec des jouets de geeks (par exemple GPG) ? J'ai toujours l'impression que cette "intégration" est surtout un truc pénible générateur de notifications intempestives, d'incompatibilité Gnome-KDE et de 36 000 demandes de mots de passe. Sans doute un traumatisme né des débuts de la mise en place de ces solutions :)
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
Oui, la DST soudoie les imams afin d'envoyer des wesh piquer les portables des pédonazis pour faire accuser les juifs, le tout sur instigation de groupes néo-marxistes sud-américains.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
Ça dépend. Je suis tombé sur un Dell pour lequel le mdp BIOS n'était ré-initialisable qu'en utilisant les coordonnées de la boîte qui l'avait achetée et en contactant leur support, avec Service Tag et tout le bordel.
Par contre c'était gratuit.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
Si l'article est déja publié, lui mettre une mauvaise notre ou un commentaire négatif n'a pas du tout le même impact.
Faudrait un système de "pertinent-inutile" avec des notes de -10 à +10 et un seuil de visibilité. Le seul problème c'est que les chercheurs auraient tendance à noter positif ce avec quoi ils sont d'accord, négatif sinon, et que les blagues d'initiés auraient systématiquement +10.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
Bref un pas en avant (licence libre reconnue par la SACEM) pour deux en arrière (plus possible de dire que la SACEM ne reconnaît pas le droit au partage et de critiquer HADOPI pour manque d'offre légale).
Ou un pas de côté : la SACEM n'est pas obligatoire.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
Apres, si tu veux m'expliquer comment faire un truc comme GMail ou de l'ajax sans code qui tourne cote client, ben tu me fais signe.
Je n'ai jamais dit que le code côté client c'était mal. Je dis qu'un truc comme Gmail ça s'appelle par exemple Thunderbird. Avec du code choisi par l'utilisateur (il peut remplacer Thunderbird par Kmail ou Evolution) indépendamment du service (t'as déjà utilisé le webmail de Yahoo chez Google ou l'inverse ? Ah zut on peut pas). Avec une économie de ressource incroyable à fonctionnalités égales. Avec de bien plus grandes facilités pour héberger soi-même le service (même si le code source de Gmail était libre, je préfère mille fois mieux me taper l'installation d'un postfix+dovecot côté serveur et Thunderbird côté client, que l'installation d'un Gmail-like sur un LAMP).
Ben ça change pas grand chose au pb, tu veux toujours valider tes données cote client avant envoi, parce que t'as pas forcement envie de te fader le reremplissage du formulaire cote serveur et que tu veux avertir l'utilisateur des pb avant meme qu'il clique sur envoyer.
D'un autre côté, si tu laisses l'utilisateur choisir son application cliente au lieu d'en proposer une toute faite en javascript, je suis absolument certain qu'elle finira par proposer de garder en mémoire les données saisies au lieu de les retaper. Exemple, 100% des clients de messagerie instantanée, en cas de mot de passe erroné ou de données rejetées par le serveur, gardent dans les champs déjà remplis les données saisies. Par contre, des sites Web qui te bennent tout, ou qui déclarent comme invalide un truc qui est valide, j'en ai vu ma dose.
Si c'est pour coder des applications aussi merdiques et les imposer à l'utilisateur final, il vaut franchement mieux le laisser choisir une application qui fonctionne, qui tourne chez lui.
A peu près aussi con que réinventer un protocole dédie pour poster 140 characteres sur une ressource.
Pas la peine, il existe : XMPP. Et il est à tous points de vue de meilleure qualité que le bordel mis en branle par l'interface de Twitter. Que ce soit "le site Web Twitter dans un navigateur" ou bien "l'API Twitter pour faire sa propre application over HTTP".
Maintenant, si t'as une meilleur idée que HTTP pour transférer des données sans authentification, je suis toute ouïe.
C'est pas forcément une "meilleure idée", ce sont des idées équivalentes : FTP, rsync, NFS, BitTorrent. Des protocoles standards qui permettent de copier des données publiées, et qui peuvent offrir des fonctionnalités supplémentaires par rapport à HTTP. rsync est réellement fait pour ne copier que ce qui a changé. BitTorrent permet de répartir la charge entre tous les gens ayant déjà téléchargé le fichier.
Maintenant, je veux bien que tu m'expliques en quoi HTTP live streaming est plus complexe et gourmand en ressource que bittorrent pour une video embarquée dans une page web. Et au passage, tu vas m'expliquer comment tu garantis de recevoir la video en premier avec bittorrent, vu que le concept c'est justement "chope ce qui est dispo, dans n'importe quel ordre, on s'en fout end' façons, c'est pour visionner offline".
BitTorrent, en l'état, n'est pas utilisable pour cet usage, on est d'accord. Mais il ne lui manque pas grand chose. HTTP non plus n'a pas été prêt pour le streaming tout de suite (sans les requêtes "Partial Content" qui permettent de récupérer la vidéo à partir d'un certain délai, ça serait franchement moins pratique. Je pense que tu vois mieux que moi de quoi je parle sur ce point :D)
Et au passage, tu vas m'expliquer comment tu garantis de recevoir la video en premier avec bittorrent, vu que le concept c'est justement "chope ce qui est dispo, dans n'importe quel ordre, on s'en fout end' façons, c'est pour visionner offline".
Je sais tres bien ce que tu vas me répondre a ce point c'est "la video, tu la mattes offline". En gros, dit moi ce dont t'as besoin, je t'expliquerais comment t'en passer.
Tu connais l'histoire des abonnés Free chez qui Youtube il rame tellement qu'ils ouvrent la page, et patientent dix minutes pour regarder une vidéo de deux minutes ? Je trouve qu'ils ressemblent furieusement à des gens qui ont appris à se passer du caractère instantané du streaming. Ils ont besoin de streaming, la réalité physique du réseau (des tuyaux congestionnés, tout simplement) leur apprend à s'en passer.
Si c'était possible de "lire du BitTorrent en streaming" je suis certain qu'avec une dizaine de seeders (autrement dit, une dizaine de gens ont vu la vidéo récemment) ça irait plus vite s'ils cliquaient sur le lien "torrent-streaming" que sur le lien "Youtube".
Tu peux utiliser RTSP, mais va falloir m'expliquer quel est l'intérêt de RTSP quand 95% des clients peuvent telecharger la video en moins de qq secondes via un protocole achement plus simple, et faire le playback de leur cote.
Je t'explique ça avec plaisir. Le RTSP, je peux le lire dans VLC, ou dans mplayer si VLC me plaît pas/plante chez moi/n'est pas dispo sur mon OS. Je peux l'enregistrer. Je peux le mettre sur pause avec le raccourci que je connais par coeur de mon "lecteur qui lit toutes mes vidéos". Je peux le minimiser et continuer à lire le texte de la page Web en n'écoutant que le son, parce que l'image c'est juste quelqu'un qui parle et ça distrait plus qu'autre chose. Ouais, c'est une bonne idée en fait, au lieu d'incruster dans une page Web une application Flash (ou sa version moderne, une balise < video >, qui contraint à utiliser le lecteur intégré au navigateur), un lien "rtsp://" c'est mieux. Bien mieux à tous points de vue. Ça fait moins "fancy kikoolol 2.0", mais c'est carrément plus pratique. Genre, je vois l'article, je peux décider de commencer à télécharger la vidéo, lire tout l'article, puis lire la vidéo, si ma connexion est pas terrible. Avec du YouMotion incrusté ça demande des manipulations rusées, différentes selon chaque site, à base de "je lance la lecture, je baisse le son, je mets sur pause, je vérifie que la barre de chargement, si y'en a une, est pleine, je remets au début, je remonte le son, je relance la lecture".
Super, et next thing you know, tu te retrouves aver 150 protocols differents.
grep -v ^# /etc/services | wc -l
556
C'est grave docteur ? La terre va arrêter de tourner ?
On peut lire une ressource, la créer, la modifier, la supprimer. Tu couvres 99,9% des besoins avec ça, sur un protocole tellement simple a comprendre que meme toi t'arrives (presque) a le comprendre. Protocole qui est implemente par quasiment tout le monde partout (forcement, simple comme il est...)
Ça c'est le beau protocole bisounours, et je suis d'accord avec toi sur ce point. Mon problème, c'est que, de facto, le protocole tu l'utilises dans 99,9% des cas avec l'application choisie par le fournisseur du service. Et cette application se présente sous la forme d'une URL HTTP qui ouvre une page dans laquelle se "passent des choses" qui sont, toutes ou presque, hors de contrôle de l'utilisateur lambda.
Maintenant, je vais te dire comment ça aurait pu, ou ça peut tourner, ce genre d'histoires. En prenant l'exemple des XEP (extensions au protocole XMPP). T'as un protocole de base (XMPP), on se rend compte qu'il permet de faire pas mal de choses, on regroupe des usages similaires dans des XEP histoire de pas éparpiller les implémentations. Un mélange de souplesse et d'intéropérabilité.
Sur le Web, le même schéma pourrait être appliqué. Combien de sites d'information se présentent sous l'aspect "article - ressources externes (vidéos, liens..) - commentaires" ? Des centaines, voire des milliers. Actuellement ce sont des milliers d'applications Web qui font toute la même chose (d'un point de vue fonctionnalités). Proposer (comme j'ai tendance à le faire) de remplacer ce bordel par des serveurs NNTP en réservant le droit d'initier un fil de discussion à ceux qui gèrent le serveur de news, c'est peut-être un peu exagéré. Mais on pourrait imaginer une vraie standardisation du modèle HTTP actuel, qui aboutirait à ce que l'utilisateur final ait un client dédié à la "lecture de journaux", qui saurait où taper pour avoir l'article, pour avoir la/les vidéos, pour lire/publier les commentaires. Autrement dit, chaque utilisateur choisit parmi plusieurs applications et garde la même sur chaque site. Au lieu d'avoir, comme actuellement, une application liée à un site. C'est pas sympa et ergonomique, comme idée ?
Et si iChat se met a afficher un flic pour les certifs auto signes, Jabber va devenir un mauvais protocole aussi?
Je parle (même si ça n'en a pas l'air) du point de vue de l'utilisation finale, tant pour celui qui consulte l'information que pour celui qui va la diffuser et/ou l'héberger. Et je montre du doigt plusieurs obstacles à une "libération d'Internet", ou "libération du Web" si tu veux. Les messages flippant des navigateurs sont un de ces obstacles, qui n'est pas présent sur d'autres clients destinés à d'autres protocoles (où on mentionne simplement la non validité du certificat, où on accepte d'associer un certificat auto-signé à un serveur particulier, sans faire déborder cette acceptation sur tous les serveurs, et en prévenant si le certificat change).
Et, pour résumer, je dirais que le Web, dans sa forme actuelle, implique nécessairement, pour celui qui publie, qui diffuse, des ressources importantes, en sécurité, en complexité de mise en place et d'administration, en puissance de calcul, et en bande passante. Et il implique également pour celui qui lit des trucs et poste des commentaires, une impuissance dans le choix de l'application et des difficultés pour contrôler et limiter le comportement de celle-ci ("Empêcher ce site de générer des boîtes de dialogue supplémentaires", c'est fou d'en arriver là, non ?).
Donc voilà, le bilan : les choix techniques faits, et le manque de recul, y compris du monde du libre, face à la "webbisation" d'Internet, font que l'utilisateur chez lui avec son serveur basse consommation et sa bande passante limitée, il ne peut pas, de façon autonome, poster un billet pour dire "regardez mon chat qui monte une échelle", mettre un lien vers une vidéo qu'il héberge (même s'il n'est pas le seul à l'héberger, merci BitTorrent), et le faire avec un semblant d'égalité par rapport à Twitter, Youtube, Facebook et leur formidable puissance de feu. Avec d'autres protocoles, et/ou une extension du Web dans d'autres directions que "faire de l'OpenGL et un OS en javascript", il pourrait. Et ça serait bon pour Internet et bon pour les internautes.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
Pour toi HTTP == application web HTML + tout le bordel : tu compares un simple serveur de communication avec un serveur qui t'expose le client utilisateur. Non, dans HTTP tu peux faire passer la même chose que ce que tu fais passer au niveau XMPP ou IRC. Il y a un overhead, certes, des contraintes qui font que ce n'est pas aussi efficace, mais si ton serveur fait le même boulot avec pour seule différence de le faire au dessus de HTTP, alors il le consommera probablement pas beaucoup plus de ressources.
De facto, l'usage est de s'en servir dans un navigateur, avec donc un gaspillage assez énorme de bande passante (re-téléchargement d'une application à chaque usage) et de puissance CPU (javascript sur navigateur sur OS, versus application native sur OS).
Je suis d'accord avec toi sur le fait qu'on peut utiliser HTTP pour faire communiquer "un client truc over HTTP" avec "un serveur truc over HTTP". Dans les faits, on met d'un côté un navigateur Web qui bouffe un maximum de RAM et de CPU, de l'autre côté généralement un LAMP qui bouffe aussi un max de ressources, par rapport à ce qui serait bouffé si c'était prosody qui parle à mcabber. (Et pas la peine de troller sur le côté rustique de mcabber, il présente plus de fonctionnalités que la totalité des applis Web de chat que j'ai pu voir).
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
J'ai renonce à l'achat du c5 à cause de l'ampli du n900, d'assez bonne qualité, mais de puissance insuffisante pour faire rendre le c5, même à bas volume...
Question de chieur : Sur le n900, le convertisseur numérique => analogique c'est un PWM coréen à 2 centimes avec un condo derrière, ou bien il mérite l'attention que tu portes à ton choix de matériel ?
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
(ainsi qu'un bon ampli pour la sortie, qu'elle soit correcte [...])
Je dirais que tu testes les enceintes et l'ampli de toute façon. Le conseil de prendre "un bon ampli" équivaut à conseiller d'avoir des "bonnes enceintes", ça fait partie du même ensemble.
Après, évidemment, il ne faut pas forcément incriminer les enceintes si le son est mauvais.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
Le fait d'envoyer du code au client repond a une problematique bien precise que tous les protocoles du monde ne peuvent resoudre.
Si cette problématique est "contrôler le plus possible le code exécuté par l'utilisateur" je suis d'accord. Mais je trouve dommage de ne pas prendre de recul critique sur cette exigence du "Web 2.0", qui est, finalement, une resucée moins performante, pleine de publicités, centralisée, limitée, de ce que les internautes faisaient y'a 20 ans : Échanger des fichiers. Discuter en temps réel. Avoir une discussion publique, organisée par fils de discussion. S'envoyer des messages différés. Avant même que le Web n'existe on pouvait faire ça (y compris la causette, CF IRC ou talk). Maintenant 99% des utilisateurs le font en utilisant une machine virtuelle nommée navigateur, qui exécute des applications choisies par le fournisseur du service. C'est.. problématique, en effet.
Le probleme, c'est de faire tourner du code cote client, ca te defrise peut etre, mais eviter un aller retour au serveur quand un formulaire est invalide ou qu'on veut juste rafraichir un div, tu vas avoir du mal a le resoudre au niveau protocolaire.
Tu parles avec une vision très "web centrée". Ton formulaire il sert à quoi, finalement ? À publier un commentaire sur LinuxFR ? Avec NNTP (par exemple) le serveur n'a pas à se soucier de la forme des données, c'est le client qui respecte le format et va, par exemple, dire "cette adresse mail est bizarre, j'envoie quand même ?" ou "Attention, message vide !". Bien évidemment je pars du principe que des données volontairement corrompues ne mettrons pas en danger ton serveur, sinon ce serait du délire de les valider avec du code qui tourne chez l'utilisateur final et hostile. Quoi que, y'a pas mal de poutrages de services Web qui se font en partie à cause de ça (path disclosure, injection SQL). Des failles récurrentes, inimaginables sur d'autres protocoles.
Le concept de ressource etant volontairement le plus vague possible, car ca peut etre n'importe quoi. Un put sur un salon de discussion, un delete sur un email ou autre.
On a réinventé TCP/IP, super :)
Et par dessus ce HTTP, ben on code des applis, qui pourraient très bien être codées en utilisant directement TCP/IP et en tournant nativement chez l'utilisateur. Moins de ressources réseau et CPU gâchées. Ah, bien sûr ça implique de communiquer avec des protocoles à peu près standard et de laisser l'utilisateur libre de choisir son implémentation, c'est embêtant : il risque de préférer l'implémentation sans publicité.
Que status.net fasse visiblement portnawak (ou plutot que ce qu'il fait t'echappe)
Ouais, j'avoue que ce gloubi-boulga m'échappe. Faut se lever de bonne heure pour comprendre et débugger une "application Web", c'est à dire, d'un point de vue système, un serveur Web qui sert des pages, lesquelles sont en fait des scripts qui tapent dans une base de données en s'authentifiant pour ensuite renvoyer du contenu HTML,et du javascript qui fait des trucs côté client afin que le client vienne faire d'autres trucs sur le serveur, ou des cookies.. Je préfère le bon vieux démon IRC, Jabber, mail, ce que tu veux, qui va simplement "faire le truc dont il est question" et dont les logs sont lisibles :)
Mais qu'est ce que ca a voir avec http ca? Serieusement? Ssl gueule en cas de certificat auto signe, oui c'est normal, vu que le but du jeu c'est d'avoir une authentificaton de la source par un tiers de confiance. Si le tiers est inconnu, il n'est pas de confiance et donc ca gueule, c'est quoi le pb au juste?
Ça a à voir avec la plupart des implémentations de HTTP : le client gueule comme un putois. Ce qui est très différent de notifier l'utilisateur. Un débutant, je peux le guider au téléphone et lui confirmer (par exemple) le certificat auto-signé d'un serveur Jabber. Par contre, sur un site Web, si Firefox lui affiche l'image d'un flic en haut à gauche, et qu'il doive confirmer qu'il "comprend les risques" avant de continuer, il va laisser tomber. Pire que ça : il n'aura même pas la possibilité d'accepter ce certificat uniquement pour un site précis, soit il fait confiance totale au propriétaire du certificat (y compris pour sa banque, ses mails..), soit il visite le site en version sans SSL. Super. Pendant ce temps, Gajim (c'est pas un projet aussi gros que Firefox hein) affiche le certificat sans hurler, préviens quand le certificat a changé, et n'accepte pas le certificat auto-signé de Claude le geek pour signer le service Jabber de Google.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Hein ?
Posté par Grunt . En réponse à la dépêche La SACEM autorise l'utilisation des licences Creative Commons Non Commerciales. Évalué à 2.
Dans ce cas c'est plus simple : je comprends pas, je signe pas.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: N'a comprend rien.
Posté par Grunt . En réponse au journal Dockmanager et KDE. Évalué à 9.
heu.. tu permets qu'on souhaite un standard qui fonctionne sur autre chose que Gnome ?
Je rappelle qu'avec ton raisonnement, il suffit de constater que 90 ou 95% des gens utilisent Windows pour en faire "le standard".
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Hein ?
Posté par Grunt . En réponse à la dépêche La SACEM autorise l'utilisation des licences Creative Commons Non Commerciales. Évalué à 8.
Je me demande si l'incapacité à lire n'est pas le plus grand mal de notre société. Musiciens qui signent des contrats sans les lire. Utilisateur qui acceptent des licences sans les lire. Électeurs qui votent pour des programmes sans les lire.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Esclavage
Posté par Grunt . En réponse au journal You wouldn't download a car !?. Évalué à 10.
Je trouve ça super simpliste cette idée d'objet qu'on imprime à la maison, exprimée ainsi.
Par "définition", un objet qu'on peut fabriquer avec une imprimante 3D est fabriqué déjà de façon entièrement automatisée, avec une poignée de gus à peu près diplômés qui surveillent une machine sophistiquée qui chie des millions de pièces par jour.
Ça serait plutôt au niveau de l'assemblage de certains trucs qu'il faut de la main d'oeuvre. Et là, l'imprimante 3D peut apporter quelque chose. Pas pour fabriquer la pièce, mais parce que l'entreprise qui fabrique la pièce et fait travailler des chinois pour l'assembler refusera de te vendre la pièce afin que tu l'assembles toi-même.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: précision
Posté par Grunt . En réponse au journal Vidéoprotection c'est efficace - témoignage.. Évalué à 10.
C'est triste ton avis sur l'énumération.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: N'a comprend rien.
Posté par Grunt . En réponse au journal Dockmanager et KDE. Évalué à 3.
Oui mais Akonadi c'est pour KDE uniquement. Donc ça pue. J'utilise KDE, mais je n'aime pas cette fragmentation des bureaux Linux. Au contraire ça serait beau d'avoir des solutions capables d'être adoptées sur d'autres OS, et d'être non-indispensables pour les OS qui n'en veulent pas.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: N'a comprend rien.
Posté par Grunt . En réponse au journal Dockmanager et KDE. Évalué à 2.
Ce qui m'ennuie, c'est que j'utilise parfois des applis KDE, parfois des applis Gnome, et Kwallet semble mal gérer les deux (Et non, KDE ne propose pas de remplaçant sérieux à Gajim).
Et puis ça serait bien d'avoir un truc qui "tout intègre", y compris par exemple les mots de passe stockés par Firefox (bon, là c'est plutôt à Firefox de tendre la main). Personnellement j'utilise Keepassx, qui permet également de stocker les mots de passe des serveurs SSH (y compris ceux où je ne peux pas "poser" ma clef publique), les services Web sensibles que je ne veux pas sauver dans le navigateur (type banque, administrations..)
Forcément, ça fait du copier/coller à la main. Mais ça serait bien d'avoir quelque chose de réellement unifié, capable de fournir automatiquement le bon mot de passe à Konqueror, à Gajim, au client SSH lancé depuis bash dans Konsole, à Firefox.. Oui, j'en demande beaucoup :)
Et, si possible, sans casser l'existant, c'est à dire sans compliquer la vie de l'utilisateur qui ne veut pas profiter de ces fonctionnalités.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: N'a comprend rien.
Posté par Grunt . En réponse au journal Dockmanager et KDE. Évalué à 6.
Aaah là je saisis, merci ! Un exemple, ça permet d'afficher sur le client de messagerie le nom de la chanson qu'on écoute, si on le souhaite. Je vois mieux :)
Bon ben vive DBUS alors.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: N'a comprend rien.
Posté par Grunt . En réponse au journal Dockmanager et KDE. Évalué à 5.
Je voulais dire, par exemple : l'application mail reçoit un fichier .ics, elle le stocke dans /tmp, l'application agenda l'y trouve. C'est comme ça que ça a l'air de marcher..
J'ai regardé du côté des "Linux Interprocess Communications" (c'est plus facile à chercher ainsi) et effectivement ça répond mieux aux besoins. T'as un exemple d'utilisation concrète dans un environnement de bureau ?
Oui, c'est fort probable que je mélange. C'est un point que j'ai toujours trouvé obscur sous Linux. Donc, le standard c'est dbus, et une application peut par exemple demander via dbus la liste des contacts de l'utilisateur, ou bien le nom du serveur SMTP disponible sur le réseau ?
(Je comprends pas pourquoi je me fais moinsser en posant la question. J'ai juste du mal à comprendre comment ces trucs fonctionnent, ce qu'ils apportent. C'est humain non ? Si quelqu'un a une doc qui explique tout ça sans balancer deux sigles par phrase je suis preneur aussi )
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
# N'a comprend rien.
Posté par Grunt . En réponse au journal Dockmanager et KDE. Évalué à 8.
Bonsoir,
J'avoue ne pas comprendre grand chose à ces concepts, à ces daemon et ces intégrations d'environnement de bureau. À mes yeux, "le bureau" c'est un gestionnaire de fenêtre, des barres de menus, des applications qui communiquent éventuellement en écrivant dans des fichiers.
Et je me sens de plus en plus paumé quand je vois de l' "intégration". Par exemple le truc KDE qui me dit "telle application veut accéder au trousseau de clef, veuillez choisir un mot de passe principal".. heu, what, wait ?
En soi je n'ai rien contre ce concept d'une "intégration" des applications. Je pense saisir l'idée : avoir des ressources globales (des contacts, des mails, un agenda), et permettre à chaque application de travailler avec et de notifier les autres (je reçois un mail avec un .ics => j'ajoute le RDV dans mon agenda d'un clic, sans manipuler le .ics moi-même). C'est à peu près ça ?
Concrètement, il y a un standard unique qui se dessine ? Les applications gèrent tout ça correctement ? Ça marche bien ? C'est compatible avec des jouets de geeks (par exemple GPG) ? J'ai toujours l'impression que cette "intégration" est surtout un truc pénible générateur de notifications intempestives, d'incompatibilité Gnome-KDE et de 36 000 demandes de mots de passe. Sans doute un traumatisme né des débuts de la mise en place de ces solutions :)
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: précision
Posté par Grunt . En réponse au journal Vidéoprotection c'est efficace - témoignage.. Évalué à 10.
Oui, la DST soudoie les imams afin d'envoyer des wesh piquer les portables des pédonazis pour faire accuser les juifs, le tout sur instigation de groupes néo-marxistes sud-américains.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: précision
Posté par Grunt . En réponse au journal Vidéoprotection c'est efficace - témoignage.. Évalué à 6.
Ça dépend. Je suis tombé sur un Dell pour lequel le mdp BIOS n'était ré-initialisable qu'en utilisant les coordonnées de la boîte qui l'avait achetée et en contactant leur support, avec Service Tag et tout le bordel.
Par contre c'était gratuit.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Réseau social
Posté par Grunt . En réponse à la dépêche Le libre accès et l'appel au boycott contre Elsevier. Évalué à 10.
Faudrait un système de "pertinent-inutile" avec des notes de -10 à +10 et un seuil de visibilité. Le seul problème c'est que les chercheurs auraient tendance à noter positif ce avec quoi ils sont d'accord, négatif sinon, et que les blagues d'initiés auraient systématiquement +10.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
# Autre choix.
Posté par Grunt . En réponse à la dépêche La SACEM autorise l'utilisation des licences Creative Commons Non Commerciales. Évalué à 10.
Ou un pas de côté : la SACEM n'est pas obligatoire.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: ca fait peur
Posté par Grunt . En réponse au journal Quelques aspects de la securite qui n'ont rien a voir avec le "Sandboxing" . Évalué à 5.
Je n'ai jamais dit que le code côté client c'était mal. Je dis qu'un truc comme Gmail ça s'appelle par exemple Thunderbird. Avec du code choisi par l'utilisateur (il peut remplacer Thunderbird par Kmail ou Evolution) indépendamment du service (t'as déjà utilisé le webmail de Yahoo chez Google ou l'inverse ? Ah zut on peut pas). Avec une économie de ressource incroyable à fonctionnalités égales. Avec de bien plus grandes facilités pour héberger soi-même le service (même si le code source de Gmail était libre, je préfère mille fois mieux me taper l'installation d'un postfix+dovecot côté serveur et Thunderbird côté client, que l'installation d'un Gmail-like sur un LAMP).
D'un autre côté, si tu laisses l'utilisateur choisir son application cliente au lieu d'en proposer une toute faite en javascript, je suis absolument certain qu'elle finira par proposer de garder en mémoire les données saisies au lieu de les retaper. Exemple, 100% des clients de messagerie instantanée, en cas de mot de passe erroné ou de données rejetées par le serveur, gardent dans les champs déjà remplis les données saisies. Par contre, des sites Web qui te bennent tout, ou qui déclarent comme invalide un truc qui est valide, j'en ai vu ma dose.
Exemple, le webmail d'Orange :
http://www.bortzmeyer.org/arreter-d-interdire-des-adresses-legales.html
Si c'est pour coder des applications aussi merdiques et les imposer à l'utilisateur final, il vaut franchement mieux le laisser choisir une application qui fonctionne, qui tourne chez lui.
Pas la peine, il existe : XMPP. Et il est à tous points de vue de meilleure qualité que le bordel mis en branle par l'interface de Twitter. Que ce soit "le site Web Twitter dans un navigateur" ou bien "l'API Twitter pour faire sa propre application over HTTP".
C'est pas forcément une "meilleure idée", ce sont des idées équivalentes : FTP, rsync, NFS, BitTorrent. Des protocoles standards qui permettent de copier des données publiées, et qui peuvent offrir des fonctionnalités supplémentaires par rapport à HTTP. rsync est réellement fait pour ne copier que ce qui a changé. BitTorrent permet de répartir la charge entre tous les gens ayant déjà téléchargé le fichier.
BitTorrent, en l'état, n'est pas utilisable pour cet usage, on est d'accord. Mais il ne lui manque pas grand chose. HTTP non plus n'a pas été prêt pour le streaming tout de suite (sans les requêtes "Partial Content" qui permettent de récupérer la vidéo à partir d'un certain délai, ça serait franchement moins pratique. Je pense que tu vois mieux que moi de quoi je parle sur ce point :D)
Tu connais l'histoire des abonnés Free chez qui Youtube il rame tellement qu'ils ouvrent la page, et patientent dix minutes pour regarder une vidéo de deux minutes ? Je trouve qu'ils ressemblent furieusement à des gens qui ont appris à se passer du caractère instantané du streaming. Ils ont besoin de streaming, la réalité physique du réseau (des tuyaux congestionnés, tout simplement) leur apprend à s'en passer.
Si c'était possible de "lire du BitTorrent en streaming" je suis certain qu'avec une dizaine de seeders (autrement dit, une dizaine de gens ont vu la vidéo récemment) ça irait plus vite s'ils cliquaient sur le lien "torrent-streaming" que sur le lien "Youtube".
Je t'explique ça avec plaisir. Le RTSP, je peux le lire dans VLC, ou dans mplayer si VLC me plaît pas/plante chez moi/n'est pas dispo sur mon OS. Je peux l'enregistrer. Je peux le mettre sur pause avec le raccourci que je connais par coeur de mon "lecteur qui lit toutes mes vidéos". Je peux le minimiser et continuer à lire le texte de la page Web en n'écoutant que le son, parce que l'image c'est juste quelqu'un qui parle et ça distrait plus qu'autre chose. Ouais, c'est une bonne idée en fait, au lieu d'incruster dans une page Web une application Flash (ou sa version moderne, une balise < video >, qui contraint à utiliser le lecteur intégré au navigateur), un lien "rtsp://" c'est mieux. Bien mieux à tous points de vue. Ça fait moins "fancy kikoolol 2.0", mais c'est carrément plus pratique. Genre, je vois l'article, je peux décider de commencer à télécharger la vidéo, lire tout l'article, puis lire la vidéo, si ma connexion est pas terrible. Avec du YouMotion incrusté ça demande des manipulations rusées, différentes selon chaque site, à base de "je lance la lecture, je baisse le son, je mets sur pause, je vérifie que la barre de chargement, si y'en a une, est pleine, je remets au début, je remonte le son, je relance la lecture".
556
C'est grave docteur ? La terre va arrêter de tourner ?
Ça c'est le beau protocole bisounours, et je suis d'accord avec toi sur ce point. Mon problème, c'est que, de facto, le protocole tu l'utilises dans 99,9% des cas avec l'application choisie par le fournisseur du service. Et cette application se présente sous la forme d'une URL HTTP qui ouvre une page dans laquelle se "passent des choses" qui sont, toutes ou presque, hors de contrôle de l'utilisateur lambda.
Maintenant, je vais te dire comment ça aurait pu, ou ça peut tourner, ce genre d'histoires. En prenant l'exemple des XEP (extensions au protocole XMPP). T'as un protocole de base (XMPP), on se rend compte qu'il permet de faire pas mal de choses, on regroupe des usages similaires dans des XEP histoire de pas éparpiller les implémentations. Un mélange de souplesse et d'intéropérabilité.
Sur le Web, le même schéma pourrait être appliqué. Combien de sites d'information se présentent sous l'aspect "article - ressources externes (vidéos, liens..) - commentaires" ? Des centaines, voire des milliers. Actuellement ce sont des milliers d'applications Web qui font toute la même chose (d'un point de vue fonctionnalités). Proposer (comme j'ai tendance à le faire) de remplacer ce bordel par des serveurs NNTP en réservant le droit d'initier un fil de discussion à ceux qui gèrent le serveur de news, c'est peut-être un peu exagéré. Mais on pourrait imaginer une vraie standardisation du modèle HTTP actuel, qui aboutirait à ce que l'utilisateur final ait un client dédié à la "lecture de journaux", qui saurait où taper pour avoir l'article, pour avoir la/les vidéos, pour lire/publier les commentaires. Autrement dit, chaque utilisateur choisit parmi plusieurs applications et garde la même sur chaque site. Au lieu d'avoir, comme actuellement, une application liée à un site. C'est pas sympa et ergonomique, comme idée ?
Je parle (même si ça n'en a pas l'air) du point de vue de l'utilisation finale, tant pour celui qui consulte l'information que pour celui qui va la diffuser et/ou l'héberger. Et je montre du doigt plusieurs obstacles à une "libération d'Internet", ou "libération du Web" si tu veux. Les messages flippant des navigateurs sont un de ces obstacles, qui n'est pas présent sur d'autres clients destinés à d'autres protocoles (où on mentionne simplement la non validité du certificat, où on accepte d'associer un certificat auto-signé à un serveur particulier, sans faire déborder cette acceptation sur tous les serveurs, et en prévenant si le certificat change).
Et, pour résumer, je dirais que le Web, dans sa forme actuelle, implique nécessairement, pour celui qui publie, qui diffuse, des ressources importantes, en sécurité, en complexité de mise en place et d'administration, en puissance de calcul, et en bande passante. Et il implique également pour celui qui lit des trucs et poste des commentaires, une impuissance dans le choix de l'application et des difficultés pour contrôler et limiter le comportement de celle-ci ("Empêcher ce site de générer des boîtes de dialogue supplémentaires", c'est fou d'en arriver là, non ?).
Donc voilà, le bilan : les choix techniques faits, et le manque de recul, y compris du monde du libre, face à la "webbisation" d'Internet, font que l'utilisateur chez lui avec son serveur basse consommation et sa bande passante limitée, il ne peut pas, de façon autonome, poster un billet pour dire "regardez mon chat qui monte une échelle", mettre un lien vers une vidéo qu'il héberge (même s'il n'est pas le seul à l'héberger, merci BitTorrent), et le faire avec un semblant d'égalité par rapport à Twitter, Youtube, Facebook et leur formidable puissance de feu. Avec d'autres protocoles, et/ou une extension du Web dans d'autres directions que "faire de l'OpenGL et un OS en javascript", il pourrait. Et ça serait bon pour Internet et bon pour les internautes.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: ca fait peur
Posté par Grunt . En réponse au journal Quelques aspects de la securite qui n'ont rien a voir avec le "Sandboxing" . Évalué à 5.
De facto, l'usage est de s'en servir dans un navigateur, avec donc un gaspillage assez énorme de bande passante (re-téléchargement d'une application à chaque usage) et de puissance CPU (javascript sur navigateur sur OS, versus application native sur OS).
Je suis d'accord avec toi sur le fait qu'on peut utiliser HTTP pour faire communiquer "un client truc over HTTP" avec "un serveur truc over HTTP". Dans les faits, on met d'un côté un navigateur Web qui bouffe un maximum de RAM et de CPU, de l'autre côté généralement un LAMP qui bouffe aussi un max de ressources, par rapport à ce qui serait bouffé si c'était prosody qui parle à mcabber. (Et pas la peine de troller sur le côté rustique de mcabber, il présente plus de fonctionnalités que la totalité des applis Web de chat que j'ai pu voir).
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: réponse du micro...
Posté par Grunt . En réponse au journal Tester votre chaîne Hi-Fi avec Qloud. Évalué à 3.
Soit tu voulais dire "compréhensible", soit tu as oublié la qualité des HP de portable.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: lecture de la courbe
Posté par Grunt . En réponse au journal Tester votre chaîne Hi-Fi avec Qloud. Évalué à 2.
Question de chieur : Sur le n900, le convertisseur numérique => analogique c'est un PWM coréen à 2 centimes avec un condo derrière, ou bien il mérite l'attention que tu portes à ton choix de matériel ?
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: lecture de la courbe
Posté par Grunt . En réponse au journal Tester votre chaîne Hi-Fi avec Qloud. Évalué à 5.
T'as d'autant plus raison, qu'une femme enceinte plate fait généralement un déni de grossesse.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: réponse du micro...
Posté par Grunt . En réponse au journal Tester votre chaîne Hi-Fi avec Qloud. Évalué à 4.
Ça dépend.. un ampli à lampes c'est de toute beauté, pour peu qu'on puisse voir un peu ses entrailles :)
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: réponse du micro...
Posté par Grunt . En réponse au journal Tester votre chaîne Hi-Fi avec Qloud. Évalué à 10.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: réponse du micro...
Posté par Grunt . En réponse au journal Tester votre chaîne Hi-Fi avec Qloud. Évalué à 3.
Autre possibilité, avoir trop compressé la musique (le seuil pour "trop" dépendant de la sensibilité de chacun).
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: réponse du micro...
Posté par Grunt . En réponse au journal Tester votre chaîne Hi-Fi avec Qloud. Évalué à 2.
Je dirais que tu testes les enceintes et l'ampli de toute façon. Le conseil de prendre "un bon ampli" équivaut à conseiller d'avoir des "bonnes enceintes", ça fait partie du même ensemble.
Après, évidemment, il ne faut pas forcément incriminer les enceintes si le son est mauvais.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: réponse du micro...
Posté par Grunt . En réponse au journal Tester votre chaîne Hi-Fi avec Qloud. Évalué à 2.
Y'a quoi comme "sources connues" de son, au rendu identique partout ? Je vois pas..
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: ca fait peur
Posté par Grunt . En réponse au journal Quelques aspects de la securite qui n'ont rien a voir avec le "Sandboxing" . Évalué à 6.
Si cette problématique est "contrôler le plus possible le code exécuté par l'utilisateur" je suis d'accord. Mais je trouve dommage de ne pas prendre de recul critique sur cette exigence du "Web 2.0", qui est, finalement, une resucée moins performante, pleine de publicités, centralisée, limitée, de ce que les internautes faisaient y'a 20 ans : Échanger des fichiers. Discuter en temps réel. Avoir une discussion publique, organisée par fils de discussion. S'envoyer des messages différés. Avant même que le Web n'existe on pouvait faire ça (y compris la causette, CF IRC ou talk). Maintenant 99% des utilisateurs le font en utilisant une machine virtuelle nommée navigateur, qui exécute des applications choisies par le fournisseur du service. C'est.. problématique, en effet.
Tu parles avec une vision très "web centrée". Ton formulaire il sert à quoi, finalement ? À publier un commentaire sur LinuxFR ? Avec NNTP (par exemple) le serveur n'a pas à se soucier de la forme des données, c'est le client qui respecte le format et va, par exemple, dire "cette adresse mail est bizarre, j'envoie quand même ?" ou "Attention, message vide !". Bien évidemment je pars du principe que des données volontairement corrompues ne mettrons pas en danger ton serveur, sinon ce serait du délire de les valider avec du code qui tourne chez l'utilisateur final et hostile. Quoi que, y'a pas mal de poutrages de services Web qui se font en partie à cause de ça (path disclosure, injection SQL). Des failles récurrentes, inimaginables sur d'autres protocoles.
On a réinventé TCP/IP, super :)
Et par dessus ce HTTP, ben on code des applis, qui pourraient très bien être codées en utilisant directement TCP/IP et en tournant nativement chez l'utilisateur. Moins de ressources réseau et CPU gâchées. Ah, bien sûr ça implique de communiquer avec des protocoles à peu près standard et de laisser l'utilisateur libre de choisir son implémentation, c'est embêtant : il risque de préférer l'implémentation sans publicité.
Ouais, j'avoue que ce gloubi-boulga m'échappe. Faut se lever de bonne heure pour comprendre et débugger une "application Web", c'est à dire, d'un point de vue système, un serveur Web qui sert des pages, lesquelles sont en fait des scripts qui tapent dans une base de données en s'authentifiant pour ensuite renvoyer du contenu HTML,et du javascript qui fait des trucs côté client afin que le client vienne faire d'autres trucs sur le serveur, ou des cookies.. Je préfère le bon vieux démon IRC, Jabber, mail, ce que tu veux, qui va simplement "faire le truc dont il est question" et dont les logs sont lisibles :)
Ça a à voir avec la plupart des implémentations de HTTP : le client gueule comme un putois. Ce qui est très différent de notifier l'utilisateur. Un débutant, je peux le guider au téléphone et lui confirmer (par exemple) le certificat auto-signé d'un serveur Jabber. Par contre, sur un site Web, si Firefox lui affiche l'image d'un flic en haut à gauche, et qu'il doive confirmer qu'il "comprend les risques" avant de continuer, il va laisser tomber. Pire que ça : il n'aura même pas la possibilité d'accepter ce certificat uniquement pour un site précis, soit il fait confiance totale au propriétaire du certificat (y compris pour sa banque, ses mails..), soit il visite le site en version sans SSL. Super. Pendant ce temps, Gajim (c'est pas un projet aussi gros que Firefox hein) affiche le certificat sans hurler, préviens quand le certificat a changé, et n'accepte pas le certificat auto-signé de Claude le geek pour signer le service Jabber de Google.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.