🚲 Tanguy Ortolo a écrit 12240 commentaires

Ensuite, j'ai l'impression que tu te focalises sur ce qui n'est finalement qu'un détail. La question posée, c'est plus: est-ce que cette liseuse est vérouillée?

Je ne crois pas, Bookeen n'aurait aucun intérêt à cela.

Est-il possible d'y installer un logiciel modifié?

Oui, seulement rien n'est fait pour le faciliter.

Avoir les sources n'est guère utile s'il est impossible de les modifier.

C'est possible, je pense. Mais difficile. Pour résumer, Bookeen n'ont pas eu le temps de définir une plate-forme pratique pour être étendue ou modifiée. Ils ont publié le code, mais c'est tout : cela suffit à modifier et à adapter le logiciel, mais ça ne rend pas du tout cette tâche aisée. :-)

Dites, ceux qui m'ont moinssé pourraient-il expliquer leur décision ? Ce journal parle de la liberté du logiciel d'une liseuse. Je signale qu'il n'est pas entièrement libre puisqu'il est capable de lire des DRM.

Si ce commentaire n'est pas pertinent, je ne vois pas ce qui peut l'être…

Ces liseuses ne sont bien évidemment pas entièrement libre, puisque :

"Formats texte lus : Adobe ePUB/PDF (avec ou sans DRM), fichiers TXT et HTML ; photo (grayscale) : JPEG, GIF et PNG"

Il manque pas le format CBR/CBZ pour les BD numériques ?

Si, il manque, mais pas dans la description, dans la réalité : ces liseuses ne prennent pas en charge ce format, ce qui est bien dommage. En pratique on utilise du PDF à la place…

L'écran est noir et blanc, alors je pense qu'il va massacrer le BD.

Pas les BD en noir et blanc petit format, comme le Geektionnerd.

–Rebecca West, The Clarion, 11/14/13

Répétez après moi : « Les dates au format américain, c'est aberrant, incohérent, moche et débile. Le format américain c'est mal, ISO 8601 c'est bien. »

Tu confonds avec awesome, je crois.

03:14:07 UTC 2038-01-19

Drôle de format, l'heure d'abord, puis la date… Ce serait plus compréhensible comme ça : 2038-01-19 03:14:07 UTC

Bah, en même temps, pas la peine de s'inquiéter, il y en aura pour tous les goûts : systemd pour ceux qui aiment, SysV init ou BSD init pour les autres. systemd ne signera pas l'arrêt de mort de ses prédécesseurs, qui continueront à être maintenus pour les besoins des BSD et de Debian.

Mais en attendant, quand quelqu'un me demande de m'inscrire sur Facebook, je réponds quoi ?

Que tu ne veux pas mais que lui peut très bien s'inscrire sur $whatever à la place. Comme ça tu retournes la situation, ce qui permet de lui montrer que ce qu'il te demande n'est pas anodin, pas plus que ce que tu lui demandes à la place.

Et comme déjà dit, tout le monde ne connait pas de dev' Debian : je fais comment moi pour la faire signer?

http://wiki.debian.org/Keysigning/Offers

Il y a plus de développeurs Debian, et dans plus d'endroits différents, qu'il n'y a d'autorités de certification SSL, je pense.

Tu as beau le répéter, ça n'en fait pas une solution : ta solution ne résout aucun problème de savoir comment deux personnes sur terre peuvent être sûrs qu'ils se parlent sans devoir faire 36 bidouilles.

En même temps, SSL ne résout pas non plus ce problème. Les autorités de certification signent n'importe quoi à condition de fournir de l'argent et un vague papier ressemblant vaguement à un truc officiel comme un relevé de compte en banque. Ce n'est pas étonnant, puisque leur intérêt financier est de mal faire leur travail de vérification.

Donc on est en train de comparer :

• SSL, un système où il est facile de se faire certifier, mais qui ne garantit absolument rien ;
• GPG, un système où se faire certifier nécessite une véritable vérification, ce qui est forcément plus compliqué, et qui garantit vraiment l'identité.

Merci, c'est précisément le genre d'explication que je cherchais. Tout s'éclaire.

Fail : il n'y a pas de pair de confiance "commun". Avec X509, si. C'est payant, oui, mais la fonctionnalité existe, j'ai un pair de confiance commun avec ceux à qui je veux parler. Pas avec PGP où c'est à toi de te démerder pour le trouver le pair.

Comme je l'ai déjà dit : téléchargez le trousseau de clefs de l'ensemble des développeurs Debian et utilisez-le comme pairs de confiance. Ils sont d'une façon générale plus fiables que les autorités de certification X.509 de toute façon.

C'est ça. Et le nommer mysqlnd pour « MySQL native driver », c'est donc débile.

Et la bibliothèque MySQL officielle aussi. Je maintiens : dans ce contexte (distinguer la bibliothèque MySQL officielle et la bibliothèque alternative), le terme « native » n'a aucun sens.

C'est bien ce que j'avais compris, et le terme « natif » n'a pas le moindre sens.

Ah, d'accord. Bon, alors le « native » n'as pas son sens intuitif (elle n'est pas plus native que la bibliothèque officielle), ni son sens inverse : il n'a tout simplement aucun sens. Parler de bibliothèque alternative serait plus pertinent.

Les extensions mysql, mysqli et pdo_mysql utilisent maintenant la bibliothèque native d'accès à MySQL mysqlnd, au lieu de la bibliothèque officielle de MySQL.

Comme ce n'était pas clair, je viens de regarder les dépendances des paquets Debian correspondants. Ma déduction : contrairement à ce qu'on pourrait penser, cette bibliothèque est « native » dans le sens où elle est rédigée en PHP, au contraire de la bibliothèque officielle de MySQL qui utilise la bibliothèque C.

Euh… Des lecteurs "ancien" ne savent pas lire la chose.

Non non non, pas des lecteurs anciens, juste des lecteurs merdiques. Un lecteur avec une prise en charge décente de MIME affichera normalement le corps du message, qui est présenté de façon tout à fait semblable à un message mixte texte/HTML.

Bof. Je ne connais pas de développeur Debian IRL. Encore moins 3.

Et ? Ça ne t'empêche pas de télécharger le trousseau de clef Debian et de le définir comme clefs de confiance.

Mais il n'y a pas de modèle avec une authorité de confiance un peu reconnue pour l'instant, donc c'est inutilisable pour moi.

Bah, tu n'as qu'à prendre le trousseau de clefs de l'ensemble des développeurs Debian par exemple, et t'imposer de ne faire confiance à une clef que si elle a été signée par trois d'entre eux : ils sont aussi dignes de confiance que les autorités de certification X.509, voire plus parce que ces autorités ont intérêt à mal faire leur travail.

Debian formant la plus grosse toile de confiance PGP de l'univers connu, ça te fait une autorité de certification sacrément puissante.

J'ai une bonne nouvelle à t'annoncer : les serveurs connus sont synchronisés entre eux. Tu trouveras exactement les mêmes clefs sur chacun d'entre eux, moyennant le temps de propagation.

Quitte à me répéter, dans la vraie vie il n'y a pas de connaissances communes.

Si. Tu as par exemple une connaissance commune entre toi et ta banque : VeriSign. Ou toute autre autorité de certification.

Mais comment faire cette vérification justement?

Par une ou plusieurs connaissances communes, considérées comme des autorités de certification.

Ce n'est pas pour rien qu'il y a des authorités de confiance en SSL, c'est pour éviter ce problème que ça a été créé.

Nawak : le modèle PGP est strictement supérieur à celui de X.509 (SSL). La seule différence entre un certificat PGP et un certificat X.509, c'est que le PGP peut être signé par plusieurs autorités alors que le X.509 peut être signé par une seule. Du coup :

• PGP permet d'implémenter un modèle pyramidal à la X.509 avec des autorités de certification, il suffit pour ça de se restreindre volontairement à une signature par certificat ;
• PGP permet aussi de faire mieux, en implémentant un modèle en toile de confiance.