🚲 Tanguy Ortolo a écrit 12091 commentaires

Ça se fait effectivement, mais ça ne peut pas être fiable, PDF n'est pas fait pour ça. Il y a par exemple plein de cas de problèmes : des documents dont le texte a été mis en chemin, des ligatures, des césures…

Git n'est pas utilisé comme ça pour le noyau. C'est Linus Torvalds qui titre les branches de ses lieutenants et qui pousse les commits, à ma connaissance.

À ton avis ? Tu imagines sérieusement que Microsoft aurait pu inventer un truc pareil ?

Un indice : [http://en.wikipedia.org/wiki/Super_key_%28keyboard_button%29].

ben le clavier déjà, change. c'est utilisable avec emacs ?

Oui, parce qu'Emacs est conçu pour être utilisable avec plein de claviers différents. Par exemple, sur nos claviers qui ne portent pas de touche Meta comme la Space Cadet d'origine, la touche Alt est utilisable à la place. Sur des claviers qui n'auraient pas de touche Alt, la touche Échap peut également servir.

En revanche, les claviers Apple sont extrêmement pour l'utilisation de la ligne de commange Unix, parce qu'il leur manque des symboles explicites tels que | et ~ et les accolades, si je me souviens bien. Ces symboles sont accessibles via des combinaisons avec AltGr, qu'il faut apprendre par cœur parce qu'elles ne sont pas indiquées sur les touches.

On parle d'installer GNU/Linux sur un ordinateur Apple, je crois. Donc le clavier, il a deux touches Contrôle, deux touches Alt, deux touches Super et plein d'autres touches dont certaines à des positions inhabituelles. Cela change la disposition du clavier, et il y a des dispositions prévues pour cela. En revanche, cela ne change strictement rien aux raccourcis utilisés, qui sont caractéristiques des logiciels, pas du clavier.

Donc une copie, qui se fait avec Super + C sous MacOS X Finder, se fera avec Contrôle + C sous GNOME Nautilus, sur la même machine. Sous GNOME, les touches Super servent plutôt pour les raccourcis liés à GNOME lui-même, je pense.

Ça marche plutôt bien, quoiqu'il y ait quelques joyeusetés à tout mettre en place. Mais dans l'ensemble, ça marche, donc.

les clefs USB normales ("mass storage"),elle sont déjà dangereuses

Non, seulement sur des systèmes mités.

vous devriez vous méfier plus que ça...

Non, ici on utilise des systèmes conçus autrement qu'avec les pieds.

(j'en ai déjà vu qui utilisaient le autorun pour installer)

Merci, mais l'autorun sans confirmation, c'est une aberration réservée aux systèmes pour neu².

je te trouve juste ignoble à juger une personne sur son physique

Juger quelqu'un sur son physique, c'est mal, sauf dans un cas : quand la personne en question fait en sorte qu'on le fasse. Par exemple, se moquer de quelqu'un de pas très grand, c'est mal, sauf s'il porte des talonnettes afin qu'on le remarque.

des A6 pour liseuses

Ça reste très, très dégradé par rapport à de l'ePub. Une liseuse, normalement, ça permet de choisir la fonte, la taille de caractère, l'orientation de l'écran, la présence ou non d'un en-tête et d'un numéro de page…

Si seulement ça pouvait tuer des majors ! Ça ferait un super slogan, non ?

« La contrefaçon tue des majors : tipiakez ! »

On pourrait même en faire une jolie affiche, je pense.

Je n'ai pas parlé de clavier… L'intérêt d'un livre papier ou d'une liseuse électronique, c'est que c'est plus confortable pour les yeux qu'un écran rétro-éclairé, mais ça n'implique pas d'être loin de son clavier et de son écran pour autant.

Mais les PDF se lisent très bien quand même, c'est juste pas le mieux. Mais c'est très bien quand même.

Félicitation si tu arrives à lire des pages de PDF A4 réduites en A6, moi j'ai moins de 15/10 d'acuité visuelle et j'en suis donc incapable…

Ces livres électroniques électroniques sont compilés en PDF. C'est dommage, cela montre que leurs auteurs n'ont jamais vu de liseuse électronique, et cela implique qu'ils sont inutilisables sur liseuse électronique, justement. Les seules utilisations possibles de ces livres, c'est de s'exploser les yeux en les lisant sur écran, ou de les imprimer intégralement…

Et quand on voit les nouveautés des bureau libres, ce n'est pas beaucoup mieux.

Tu étais où quand KDE 4 et GNOME 3 ? Je ne sais pas ce qu'il te faut…

Qu'est-ce qui ne va pas à ce système pour ne pas l'utiliser ? Pour moi ça me semble plus simple, et plus générique.

Plus générique, oui, et c'est d'ailleurs ce qui se fait en général lorsque le développeur amont ne fournit pas de dépôt de versions, grâce à des outils faits pour automatiser cela, mais pas plus simple. L'historique amont m'est utile pour diverses raisons, par exemple :

• pour rétroporter des correctifs ;
• pour prendre en compte une nouvelle version — un simple git merge, opération à laquelle je suis habituée.

Non, si je dois maintenir moi-même un contenu de dépôt semblable au tarball, cela ne me pose pas plus de problème que ça, je trouve juste cela dommage, mais je le ferai avec une branche parallèle basée sur celles de ton dépôt.

pour que les éditeurs se mettent d'accord entre eux pour ne pas trop se marcher sur les pattes

Ils ne pourraient pas. Le jour où une entreprise développant LibreOffice choisira de supprimer la fonctionnalité d'export PDF parce que cela nuit à leur partenaire Adobe, cette fonctionnalité sera remise en place par la communauté, au moyen d'un fork si nécessaire. Il n'y a pas de place pour les fonctionnalités négatives (antifeatures) dans le logiciel libre.

Pour ceux qui opposeraient qu'un réseau de confiance est trop compliqué à construire, je rappellerai que de tels systèmes n'ont rien de moins que le système pyramidal X.509, mais uniquement une caractéristique de *plus* : la possibilité d'avoir plusieurs signatures sur un certificat.

Par conséquent, un système de réseau de confiance permet de faire tout ce qu'un modèle pyramidal permet. En particulier, il est tout à fait possible d'implémenter un modèle pyramidal ou hybride à partir d'un système de réseau de confiance.

Un réseau de confiance à la PGP ?

Je ne sais pas comment est construit un paquet DEB, mais je ne pense pas que beaucoup de distribs ont besoin d'avoir dans Git l'équivalent du tarball.

Comme je l'ai détaillé plus haut, Debian non plus, mais il est pratique de pouvoir le faire, et c'est considéré comme une bonne chose.

Par contre ce que je ne comprends pas, c'est de vouloir avoir dans Git l'équivalent du tarball.

Ah, c'est vrai que j'avais oublié d'expliquer cela. Ce n'est effectivement pas une nécessité, tout comme il n'est pas non plus nécessaire d'utiliser un gestionnaire de version d'ailleurs. C'est simplement pratique : nous disposons d'un outil nommé pristine-tar qui permet de stocker les informations nécessaires à la reconstruction du tarball exact dans le gestionnaire de versions, ce qui permet de tout mettre dedans et simplifie d'autant la gestion du paquet.

pristine-tar fonctionne en stockant dans une branche détachée — c'est à dire sans origine commune avec quelque autre branche — quelques informations : un commit d'origine proche du contenu du tarball, la compression utilisée et un delta binaire entre le tarball ainsi généré et l'original. On essaie de minimiser ce delta en utilisant un commit d'origine aussi proche que possible du contenu du tarball : un fichier de trop, tel un .gitignore ne posera pas de problème, mais plusieurs gros fichiers produiront un gros delta, ce qui n'est ni élégant ni efficace.

Indépendamment de la gestion de version, un paquet Debian source est constitué grosso modo de deux fichiers : le tarball d'origine et une archive contenant les fichiers spécifiques au paquet Debian. Lors de la décompression de ce paquet source, le tarball d'origine est simplement extrait, et les fichiers spécifiques à Debian sont placés dans un répertoire debian/, pour former ce que j'appellerais un répertoire de travail de paquet Debian. Lorsqu'on choisit de travailler sous contrôle de version, on y stocke le plus souvent tout le contenu du répertoire de travail, comprenant donc le contenu du tarball d'origine et le répertoire debian/.

Le dépôt de contrôle de version contient donc de quoi travailler, mais pas de quoi reconstruire le tarball d'origine, donc a fortiori pas de quoi reconstruire le paquet source qui comprend ce tarball d'origine. pristine-tar pallie cela, en versionnant également de quoi reconstruire ce tarball.

Alors, le VHD, ça a l'air équivalent à une image brute de n'importe quoi, donc aucun problème à monter ça en lecture-écriture du moment que le système de fichiers qui est dessus est approprié.

Je ne crois pas que le système de fichiers ISO 9660 ait jamais été conçu pour être utilisé en écriture : tout comme SquashFS, il me semble plutôt fait pour être généré puis utilisé en lecture seule.

En revanche, il existe un système de fichiers qui a été conçu entre autres pour cela : UDF. Et il n'y a aucun problème à monter une image UDF en lecture-écriture.

Monkeysphere. Dommage qu'il nécessite de laisser tourner un agent Monkeysphere.

Très bien, sauf que ces mécanismes ne répondent absolument pas au problème principal de sécurité, qui est la corruption d'une autorité de certification, qui est présenté ici.

Je vois, c'est une contrainte pénible de GNOME, donc. Eh bien, ça revient simplement à déplacer et à multiplier ce travail sur chaque distribution utilisant Git, tant pis…

Si tu peux faire le calcul attendu, hors éléments secrets, je ne vois pas ce qui pourrait empêcher ton attaquant de renvoyer les bonnes valeurs

Pire : l'attaquant peut tout simplement faire sauter le code de vérification, c'est beaucoup plus simple.