🚲 Tanguy Ortolo a écrit 12224 commentaires

Oui, c'est exact, et la clef PGP de CAcert est également signée par des tas d'inconscients qui n'ont jamais rencontré CAcert en personne pour vérifier son identité…

Plus intéressant, ça dépend de tes critères. Les administrations et autres grosses organisations officielles adorent le modèle de confiance pyramidal imposé par la norme X.509, dont CAcert participe. Ce modèle est par ailleurs dangereux, en ce qu'il encourage de gros problèmes d'organisation et de sécurité (concrètement, une guilde d'autorités très restreinte, et qui font mal leur travail de vérification).

Note que ce modèle pyramidal peut être mis en œuvre au sein du modèle de réseau de confiance d'OpenPGP, qui ne fait que l'étendre, mais que ce n'est pas utilisé comme cela en pratique : les utilisateurs de PGP sont généralement trop sérieux et soigneux pour se permettre de faire des vérifications hâtives comme les autorités de certification X.509.

Plus simple, pas vraiment, c'est là une question d'ergonomie des logiciels, et en pratique une fois que tu disposes d'une paire de clefs OpenPGP et ou X.509, c'est aussi simple que de cocher une case « signer », ou pour tes correspondants de cocher une case « chiffer » s'ils disposent de ta clef. Ce qui est plus compliqué, c'est la gestion du réseau de confiance OpenPGP, qui n'a pas lieu d'être avec X.509 puisqu'on s'en charge pour toi.

si je ne me trompes ca, ce n'est pas incompatible.

Tu te trompes, c'est incompatible. Il existe deux normes de chiffrement et de signature de messages : PGP/MIME et S/MIME.

CACert te fournit les certificats utilisateurs et un "tiers de confiance" avec leur serveur.

Exact, mais il s'agit de certificats X.509 et non de certificats OpenPGP.

et tu vas utiliser les certificats pour coder/decoder tes emails avec openPGP

Non : déjà, OpenPGP est une norme et non un logiciel, et ensuite, ces certificats X.509 sont utilisables pour chiffrer — et non coder, autant utiliser la bonne terminologie — ou vérifier la signature de messages à la norme S/MIME uniquement.

En revanche, ce qui est possible — mais pas facile à mettre en œuvre en pratique —, c'est d'utiliser une même paire de clef avec OpenPGP et S/MIME, mais ça n'apporte pas grand chose.

Pour les prochains événements, il faudrait :

• les annoncer un peu plus tôt ;
• les signaler à CAcert pour qu'ils soient officiellement annoncés : CAcert propose un système d'alertes pour signaler aux utilisateurs les événements proches de chez eux !

http://wiki.cacert.org/Events/UpcomingEvents

Pour les exemples, il faut utiliser les noms de domaines dédiés à cela : example.com, example.net, example.org, example.edu et *.example.

J'aimerai recevoir les mails sur nimporte_quoi@utilisateur.mondomaine.tld dans le dossier nimporte_quoi sur le compte IMAP de utilisateur@mondomaine.tld.

Le moyen le plus simple et propre de mettre cela en œuvre dans le DNS, c'est :

utilisateur.mondomaine.tld. CNAME mondomaine.tld.
mondomaine.tld. MX serveur.mondomaine.tld.
serveur.mondomaine.tld. A …
                        AAAA …

C'est normal, ou du moins compréhensible. Une bibliothèque de prêt, comme son nom l'indique, ça propose aux gens des prêts de livre. Or qu'est-ce qu'un prêt ? Un don limité dans le temps à cause des contraintes matérielles : si la bibliothèque donnait les livres, elle ne les aurait plus.

Bref, la notion même de prêt n'est qu'une forme dégradée du don, et n'existe qu'à cause de ces contraintes matérielles. Or, ces contraintes n'existent pas pour des œuvres sous forme numérique tellement il est alors facile de les copier. En clair, le prêter n'a aucun sens dans un système de distribution dématérialisé. Une bibliothèque numérique n'a aucune raison de prêter des livres puisqu'elle pourrait les donner sans rien y perdre.

Du coup, à cause de la pression induite par le vieux système de droit d'auteur, on introduit des verrous pour reproduire les contraintes de rareté qui règnent dans le monde des objets matériels.

Il pourrait, il devrait y avoir des bibliothèques de don. Seulement, je doute que la clique des ayant-droits soit d'accord avec cette idée, mais après tout, seraient-ils d'accord avec l'idée des bibliothèques de prêts si elles n'existaient pas et étaient proposées aujourd'hui par — rêvons un peu — une ministre de la culture ?

Howi !

Ce qu'il faut comprendre, c'est que globalement les échanges de puissance via les murs internes s'annulent. Il n'y a que les pertes via les murs externes qui comptent. Si tu chauffes plus ton appartement, la situation du mur externe de tes voisins ne change pas, par contre les pertes via tes murs externes augmentent. Donc déperdition globale d'énergie plus importante.

Plus importante que quoi ? Que si tu chauffais toi-même ton appartement ? Non, parce que dans ce cas sa température serait supérieure vu que tu bénéficierais à la fois du chauffage par tes voisins et de ton propre chauffage. Du coup, la déperdition de chaleur par tes murs extérieurs serait supérieure.

Que si tu ne chauffais pas davantage ton appartement mais si tes voisins isolaient soigneusement les murs qui les séparent de toi pour éviter de te chauffer à leurs frais ? Effectivement, mais dans ce cas la température de ton appartement baisserait tellement que tu finirais pas mettre le chauffage, rétablissant à peu près la même situation.

Désolé si je casse des rêves, mais une méthode automatique sera forcément considérée comme crade par d'authentiques debianeux, tout simplement parce que les critères de qualité de Debian impliquent un travail manuel, ne serait-ce que pour remplir des informations : une description du paquet, le détail des licences utilisées et les information d'attribution, ou encore le détail de l'origine et du but d'un patch s'il y en a besoin.

En revanche, le gros du travail est automatisable dans la grande majorité des cas. Un logiciel bien fichu en amont, utilisant un système de construction à peu près standard, pourra être empaqueté assez facilement. Sous la forme d'un paquet basique, à affiner pour en faire quelque chose d'acceptable pour Debian.

Ça tombe bien, les logiciels écrits en Python, quand on veut les lancer, on ne les nomme pas .py…

C'est effectivement ce qui est fait pour beaucoup de logiciels en Java il me semblent. En revanche, question d'efficacité en mémoire :

exec java -jar le_binaire.jar

Alors, faire des paquets Debian, fondamentalement, ce n'est pas difficile, un paquet binaire Debian est simplement une archive contenant deux archives : l'une avec les fichier à installer et l'autre avec les méta-informations (dépendances, description…) et les éventuels scripts supplémentaires pour l'installation et la désinstallation.

En revanche, ce qui demande plus de savoir-faire, c'est de faire un paquet Debian propre, c'est à dire construit selon les conventions et les contraintes de qualité de Debian. Cela implique notamment : de le construire à partir d'un paquet source Debian, d'avoir une arborescence de paquet source qui respecte les conventions, d'utiliser les outils standards (et donc d'apprendre à s'en servir, comme Ant pour Java par exemple), de fournir des pages de manuel…

Effectivement, ce genre de travail demande des compétences qui n'intéressent pas beaucoup les développeurs, d'où l'intérêt de trouver, idéalement, un mainteneur Debian pour s'occuper du paquet.

Des mitaines, ça doit être bien pour coder malgré le froid non ?

Attention pour le changement de périphérique de stockage, s'il utilise déjà une Flash, à l'époque de cette machine ce n'était pas vraiment standardisé. Il y a à ma connaissances pas mal de connectiques possibles pour les périphériques de stockage de ces petites machines :

1. du P-ATA sur connecteur physique Mini-PCIe ;
2. un bidule propriétaire Asus nommé ZIF, je crois ;
3. du vrai Mini-PCIe ;
4. du S-ATA branché de façon non standard sur connecteur physique Mini-PCIe ;
5. du Mini-SATA, autrement dit du S-ATA branché sur Mini-PCIe mais de façon standard cette fois-ci.

Quelques remarques sur cette liste :

• tout le bordel non standard date d'avant que les constructeurs ne finissent par se mettre d'accord sur le Mini-SATA actuel ;
• les constructeurs sont des tarés, lorsqu'ils veulent développer une nouvelle connectique, ils réutilisent un connecteur physique existant d'une façon incompatible.

Une seule chose m'inquiète. Au final, est-ce le plus rentable (je ne parle pas de ma facture EDF, je parle de la communauté). Pour maintenir mon appart à 18, est-ce que le surcout de chauffage des voisins est moins important que mon économie ?

C'est leur problème, pas le tien, s'ils aiment vivre à 22°C toute l'année et s'ils ont du fric à dépenser là-dedans.

Chez moi, le chauffage est inutile toute l'année : mon appartement est entouré de gens qui se surchauffent, et traversé par des canalisations de chauffage et d'eau chaude sanitaire. Résultat, sauf très grands froids, je suis chauffé par mes voisins ! :-)

En plus ce sont des conneries ça : si Mozilla a un problème avec GStreamer, ils peuvent régler ce problème, les développeurs GStreamer devraient plutôt apprécier.

Non, il a un château dans le corps, visiblement.

Perdue ? Tous les appareils sous Android ne sont-ils pas capables de lire de le WebM ?

(à ce propos, savez-vous quelles distros le proposent par défaut ?)

Toutes devraient pouvoir le faire : si je me souviens bien, la MPEG-LA donne l'autorisation d'utiliser ses brevets sans restriction pour le décodage logiciel. Pour ce qui est du codage logiciel et du décodage matériel, c'est une autre paire de manches.

Eh bien, au moins on sait ce que ça vaut, les conviction à propos des formats ouverts, chez Mozilla…

C'est ce qu'on appelle un retournement de veste opportuniste. Pas cool.

Peut être mais les Humble Frozenbyte, Synapse et Introversion Bundle étaient compatibles Linux EUX …

Ce n'était pas forcément toujours une réussite, mais ils essayaient au moins, et grâce à la pression d'Humble d'ailleurs. Et puis, ils étaient sans DRM, eux.

Oui oui, c'est ça, un H. Moi et les sigles…

L'annonce de ce nouveau pack sur leur blog est intéressante, et les commentaires encore plus. On y apprend notamment :

• qu'ils sont en train de décevoir massivement leurs fans ;
• que le studio TNQ était un promoteur de la loi SOPA.