Et pour relancer le même recherche, un peu modifier pour l'affiner ? Il faudrait aussi que ça permette de la récupérer pour l'éditer : ce serait parfait, mais j'ai du mal à imaginer comment un truc pareil pourrait être intégré à la zone d'adresse.
Pas la peine de te fatiguer, comme le mentionne ce tutoriel de façon un peu laconique et simplifiée, Windows est incapable de lire plusieurs partitions sur un périphérique externe, et s'arrêtera à la première. Quoi que tu fasse, toutes les autres seront inaccessibles depuis ce système d'exploitation, il est donc inutile d'essayer de les adapter, ça ne changera rien.
Parfait. Ça installer l'exécutable de GRUB sur la partition que tu as dédiée à cela, puis ça installe dans la MBR un code qui demande au BIOS de l'exécuter.
Mais dans la partition DISTRI, je ne suis pas sur que grub2 trouve tout seul les .iso que je vais mettre dans /DISTRI/_ISO/.
Ça c'est sûr, il ne les trouvera pas « tout seul ». GRUB n'est pas un outil magique, il fait ce que tu lui dit, et il est certes capable de lire le contenu d'une image de système de fichiers, mais encore faut-il le lui demander.
C'est bête mais j'ai déjà installé grub avec cette ligne :
Tu as effectivement déjà installer GRUB pour UEFI, ce qui a mis l'exécutable correspondant dans /mnt/EFI, où je suppose que tu avais montée la partition système EFI que tu avais définie et formatée précédemment. Il est normal de devoir utiliser une seconde commande pour installer GRUB pour BIOS (autrement dit GRUB PC), si tu veux que ta clef soit démarrable sur les deux systèmes.
Pourquoi ne pas installer lancer cette ligne de la même manière? (--boot-directory=/mnt/DISTRI/boot)
Parce que, là où GRUB EFI s'installer sur le système de fichiers d'un partition système EFI (--efi-directory=/mnt/EFI), GRUB PC s'installer sur un périphérique complet (/dev/sdc).
Il faut modifier le fichier grub.cfg mais ou le modifier aussi, …
Alors là, ça va dépendre de ce que tu veux faire. À ce niveau de personnalisation de clef USB démarrable, il faut vraiment que tu te familiarise avec le fonctionnement de GRUB et sa configuration.
Dans DISTRI, j'ai le dossier grub2 avec :
-dossier fonts
-fichier grubenv
-dossier i386-pc
-locale
-x86_64-efi
C'est normal, même si je trouve vraiment affreux de mettre ça dans …/DISTRI plutôt que le standard …/boot.
Non, elle ne sert pas à ça. Vraiment, ça n'a rien à voir.
Pourquoi elle ne sert à rien du tout?
Parce que, elle installe GRUB en début de partition, dans un espace non utilisé par le système de fichiers, du moins elle le ferait si le système de fichier en question était prévu pour cela, ce qui n'est pas le cas avec FAT. Et que, à moins d'utiliser ensuite un micro-chargeur de démarrage qui va charger ce code, cette installation sera tout simplement inutilisée.
*4ème partition : 4,7 Go DISTRIBUTION type FAT32 => permet de lancer plusieurs distributions avec grub2
Au fait, pourquoi FAT 32 ? Cette partition n'est pas destinée à être utilisée sous Windows, et il devrait sembler évident que FAT 32 n'est pas le système de fichier idéal pour travailler sous Linux, tant il est déficient (pas de liens symboliques, notamment).
Pour info, si tu avais utilisé quelque chose comme Ext2, ta dernière commande, d'installation de GRUB embarqué dans une partition, aurait correctement fonctionné, bien qu'elle ne serve en pratique à rien du tout.
Non, en tout cas pas pour y embarquer GRUB. J'explique. Pour pouvoir être chargé au démarrage par un BIOS, GRUB doit être écrit quelque part sur le périphérique, de façon linéaire. Traditionnellement, il s'installait ainsi dans l'espace interstitiel situé entre la MBR et la première partition. Ce n'est pas possible avec un partitionnement GPT, où cet espace n'existe pas, c'est pourquoi il faut alors dédier une partition à GRUB, ce que tu as fait.
l existe une autre alternative, qui consiste à l'embarquer dans une zone dédiée à cela dans un système de fichier prévu pour cet usage, c'est à dire un système de fichier qui laisse volontairement sur sa partition une zone qu'il n'utilisera pas. Avec ta commande grub-install […] /dev/sdc4, c'est ce que tu essaies de faire, sans doute par erreur : installer GRUB dans un espace libre sur /dev/sdc4. Sauf que cette partition est formatée en FAT, et que le système de fichiers FAT n'a pas de zone réservée à cet usage, d'où :
grub2-install : attention : Le système de fichiers « fat » ne prend pas en charge l'embarquage.
Il y a une autre possibilité, qui consiste à installer GRUB comme un fichier, qui peut donc très bien se retrouver sur le périphérique en plusieurs blocs non adjacents, et qui ne pourra donc pas être chargé tel quel par le BIOS. Il faut ensuite déterminer les adresses de ces blocs, et créer un code qui demande au BIOS de charger ces blocs. Cette méthode utilise une liste de blocs, et c'est effectivement moins fiable, donc refusé par GRUB par défaut :
grub2-install : attention : L'embarquage est impossible. GRUB ne peut être installé sur cette configuration qu'en utilisant les listes de blocs. Cependant, les listes de blocs ne sont PAS fiables et leur utilisation est déconseillée..
grub2-install : erreur : refus de continuer avec les listes de blocs.
Il faut donc que tu utilises la méthode standard, en demandant à GRUB de s'installer sur ta clef, et non pas sur une partition, avec un grub-install /dev/sdc. Il trouvera tout seul la partition que tu lui as dédiée, et s'y installera sans problème.
Aussi, que signifie le système de fichier EF02 et EF00?
Ce ne sont pas des systèmes de fichiers, mais des types de partition, ou plus exactement, des identifiants utilisés par les outils de partitionnement GPT fdisk pour désigner les types de partition suivants :
EFI system partition : c'est ce qui indique qu'une partition donnée doit être prise en compte par l'UEFI de la carte mère, qui va chercher à y lire un système de fichiers FAT (ou éventuellement autre chose qu'elle prendrait en charge, comme un HFS+ chez Apple) pour y chercher un fichier à exécuter comme chargeur de démarrage. Dans ton cas, cette partition sera formatée en FAT 32 et contiendra l'exécutable principal de GRUB.
BIOS boot partition : c'est ce qui indique à un chargeur de démarrage pour BIOS qu'il peut s'y installer. C'est nécessaire parce qu'en partitionnement MBR, ou dans la MBR de compatibilité d'une GPT, la place pour le code de démarrage est réduite à 512 octets, ce qui est insuffisant pour y placer quelque chose comme GRUB. Avec une pure MBR, il y a un espace interstitiel entre la table de partition et la première partition, où GRUB peut aller installer son code. En revanche, avec une GPT, cet espace n'existe pas et il est donc nécessaire de dédier une partition à cet usage. À noter que cette partition n'est pas destinée à être formatée, GRUB ira simplement y écrire linérairement son code, sans système de fichier.
Ce n'est pas cela que je reproche à une zone d'adresse et de recherche unifiée, mais l'impossibilité de rejouer une recherche dans un moteur différent sans avoir à la saisir à nouveau, puisqu'elle aura été remplacée par une URL.
Relis mon second paragraphe, qui répond exactement à ton objection :
Je vois venir une objection évidente : la zone d'URL peut très bien proposer une recherche sur plusieurs moteurs. Sauf que, une fois la recherche effectuée, on se retrouve sur une page dont l'adresse a remplacé les termes de la recherche, et par conséquent, si on s'aperçoit que la carte OpenStreetMap du village de Saint-Mathieu-en-Cambrousse n'a pas les noms des rues, pour rechercher le même endroit sur Yahoo! Maps, on doit saisir à nouveau la recherche. Alors qu'avec la zone de recherche dédiée, pour relancer la recherche, il suffit de retourner dans celle-ci, qui contient toujours les termes de la recherche, et de la relancer sur un autre moteur.
Je ne sais pas quel est le problème chez toi, mais Let's Encrypt émet sans problème des certificats pour plusieurs noms de domaine, même servis par un serveur qui n'a qu'une seul adresse IP publique.
Personnellement je développe des interfaces web, et j'utilise le JavaScript, et pas uniquement pour "embellir" l'interface (ajouter des effets qui améliore l'expérience utilisateur (UX pour les intimes)), mais également pour récupérer des données JSON san devoir recharger toute l'interface.
Pour que ça « aille plus vite » en somme ? C'est amusant, parce qu'en désactivant JavaScript, ça ne va généralement pas plus lentement, plutôt beaucoup, beaucoup plus vite.
Imaginez que le serveurs soit compromis et qu'il usurpe votre page de paiement.
Et bien ? Le certificat n'est pas en cause là-dedans : une autorité de certification ne garantit qu'une chose, un identité, ici un nom de domaine, pas l'usage qu'on en fait ou la sécurité du serveur sur lequel elle est utilisée.
C'est ce que je dis, c'est l'alternative ordinaire, moins directe, donc plus lente, plus intrusive en matière de respect de la vie privée, et dépendant d'un service privé unique, avec tout ce que cela implique en matière de SPOF et de concentration de pouvoir. Bref, c'est moins bien, donc autant laisser cela aux béotiens.
Pour le moment vous pouvez essayer […] un champ unique fusionnant la barre d'adresse et celle de recherche (Universal Search)
Ça, j'espère vraiment que ce ne sera pas retenu, ou alors de façon facultative, parce que les zones d'adresse et de recherche séparées sont vraiment un avantage de Firefox, particulièrement utile quand on utilise plusieurs moteurs de recherche. Et tout le monde gagnerait à utiliser plusieurs moteurs de recherche, parce que quand on cherche des informations sur la ville de Seattle, il est plus rapide d'aller directement voir la page Wikipédia correspondante, que d'aller demander à DuckDuckGo, pour aller indirectement au même endroit, et ainsi de suite pour la météo à Toulouse (recherche Méteo France), les séances de films à Montpellier (recherche Allociné) ou le plan de la ville de Cannes (recherche OpenStreetMap).
Je vois venir une objection évidente : la zone d'URL peut très bien proposer une recherche sur plusieurs moteurs. Sauf que, une fois la recherche effectuée, on se retrouve sur une page dont l'adresse a remplacé les termes de la recherche, et par conséquent, si on s'aperçoit que la carte OpenStreetMap du village de Saint-Mathieu-en-Cambrousse n'a pas les noms des rues, pour rechercher le même endroit sur Yahoo! Maps, on doit saisir à nouveau la recherche. Alors qu'avec la zone de recherche dédiée, pour relancer la recherche, il suffit de retourner dans celle-ci, qui contient toujours les termes de la recherche, et de la relancer sur un autre moteur.
Oui, tout comme Windows Millennium Edition était le dernier de la lignée non NT. Ça ne change rien au fait que Mac OS X succède à Mac OS 9, et constitue, commercialement parlant, la version majeure suivante de la lignée de système d'exploitation Mac OS.
Je ne sais pas trop comment lire ça, vu que ça a l'air à moitié sérieux, mais :
Les nouveaux systèmes d'exploitation, iOS en version 10 et OS X qui serait à l'occasion renommé… MacOS ! Un nom dans lequel on peut voir, outre l'aspect "retour aux sources" (qui renoue avec la glorieuse époque de l'invention du premier système à interface graphique pilotée à la souris), une volonté affichée de se rapprocher encore plus de la convivialité attendue d'un OS grand-public, par la suppression du "X" marquant l'héritage un peu trop lourd et nerdy d'Unix…
Il me semblait que ce système d'exploitation, qui faisait suite à Mac OS 9, se nommait à l'origine Mac OS X, pour Mac OS, 10e version.
Possibilité de feinter un site en changeant le user agent pour tester son design adaptatif.
C'est sans doute utile pour effectuer des tests, mais l'utilisation principale du changement d'User-Agent n'est-elle pas plutôt le contournement des discriminations ?
Le retour en arrière, ça peut marcher, mais ce n'est pas du tout prévu. C'est un peu logique en même temps : si à chaque nouvelle version d'un paquet on veille à ce que tout soit bien migré depuis les versions précédentes, dans chaque version on n'a pas du tout veillé à ce que tout soit bien migré depuis une version future, c'est impossible !
Donc dans ce cas-là, c'est pas mal si j'ai une version qui "stabilisée" pendant quelques jours, avant que je ne fasse des déploiement de mises à jours.
Ce n'est pas vraiment ça non plus. Les mises à jour n'arrivent pas dans testing par paquets tous les dix jours, elles arrivent continument, avec dix jours (ou cinq, la plupart du temps, en fait) de retard par rapport à leur arrivée dans unstable. Ou plus pour les mises à jour boguées, qui n'entrent pas dans testing tant que ça n'a pas été corrigé, parce que tel est le bug de la distinction entre unstable et testing, bloquer les mise à jour qui introduisent des bogues critiques.
Je ne sais pas d’où tu sors ces 10 jours. Mais j’imagine que c’est une moyenne au doigt mouillé.
Pas du tout, ça vient de la Référence du Développeur Debian. Hors période de gel, les paquets envoyés dans unstable y restent un certain temps, qui dépend de la priorité définie par leur mainteneur pour cette mise à jour (10 jours pour un priorité faible, 5 pour une priorité moyenne, 2 pour une priorité élevée).
Ça fait des années que j’utilise Debian et il est évident que ce qui s’apparente le plus à une rolling release c’est unstable. Testing est une sorte de version béta de la prochaine stable (qui remplacera victorieusement son illustre prédécétrice) à destination de ceux qui testent sérieusement.
En ce qui me concerne, ça fait des années que je suis Développeur Debian, et si je suis loin de tout savoir à ce sujet, je suis à peu près au fait du fonctionnement des différentes version (en interne, on parle de distributions, à ne pas confondre avec différentes distributions GNU/Linux…).
Testing est techniquement une distribution à intégration continue différée, hors des périodes de gel. En période de gel, c'est figé en effet.
Unstable est une distribution à intégration continue immédiate, et elle est tout également concernée par le gel, de façon plus subtile : lorsque la testing est gelée, c'est toujours principalement la unstable qui sert recevoir les mises à jour, à ceci près qu'il ne s'agit plus de nouvelles versions mais seulement de corrections de bugs. Par conséquent, on évite d'envoyer de nouvelles versions dans unstable, qui ne seraient en aucun cas acceptées dans testing, et qui bloqueraient les envois de corrections pour des versions antérieures présentes dans testing.
Concrètement, supposons qu'en période de gel, testing contienne autojump 23-2. Arrive autojump version 24, et disons que je l'empaquette pour envoyer un autojump 24-1 dans unstable. On se retrouve alors avec, dans testing, autojump 23-2, et dans unstable, autojump 24-1. Là-dessus, quelqu'un découvre un bug critique sur autojump 23-2, et je prépare un paquet autojump 23-3 corrigeant cela. Problème, je ne peux pas l'envoyer dans unstable, qui contient autojump 24-1 qui est une version supérieure. Ce n'est pas dramatique, je dois alors l'envoyer dans testing-proposed-updates qui est faite pour cela, mais comme c'est un peu agaçant, en pratique on évite ce genre de cas, et, en période de gel, on évite d'envoyer des nouvelles versions dans unstable, préférant utiliser pour cela experimental.
Tout ça pour dire que si unstable est effectivement ce qui s'apparente le plus à une distribution à intégration continue, il ne faut pas non plus s'attendre à ce qu'elle soit toujours mise à jour au même rythme : en période de gel de la testing, son évolution sera également partiellement figée !
Les nouveautés arrivent dans unstable, puis, après dix jours, si aucun bug critique n'y a été détecté, dans testing.
La conséquence évidente, c'est qu'avec unstable, tu as les problèmes et les corrections en direct. Avec testing, tu évites les problèmes qui auront été détectés à temps — pendant les dix jours sus-mentionnés —, mais pas ceux qui ne l'auront pas été, pour lesquelles les corrections seront d'autant plus longues à arriver.
Personnellement, je recommanderais unstable si le but est vraiment de tester Debian pour contribuer à détecter les problèmes (il faut bien que quelqu'un le fasse !), et testing pour un usage quotidien averti (ce n'est pas une distribution stable !), en prenant au besoin des paquets précis d'unstable si ceux-ci apportent des corrections qui ne sont pas encore arrivées dans testing.
Oui mais à la limite, que la personne ne soit pas authentifiée ce n'est pas grave. Ce qui importe c'est que ma société le soit.
Dans ce cas ce n'est pas vraiment comparable à une signature, plutôt à un tampon en fait. Et pour le coup, DKIM répond très bien à ce besoin : si on doit pouvoir fournir une indication fiable, vérifiable a posteriori, que tel message provient bien de ton organisation, une signature DKIM fera très bien l'affaire.
Ce n'est peut-être pas une preuve qui sera acceptée sans argumentation par un tribunal, mais avec une expertise qui va bien, ça devrait être tout à fait concluant.
Voilà mais là ça dépend aussi du but de la signature. Si c'est pour avoir une preuve légale, mieux vaut une autorité de certification (qui est la garante de la fiabilité, donc la faute retombe sur eux).
Ça tombe bien, c'est faisable avec PGP, dont le modèle est un sur-ensemble de celui de X.509. En fait, n'importe qui peut être autorité de certification, techniquement parlant j'entends. Administrativement, c'est différent, mais toujours est-il qu'il est tout à fait possible pour des autorités de certification ayant pignon sur rue de signer des clefs PGP, en engageant leur responsabilité comme il se doit (et en faisant des vérifications merdiques, parce que ce sont des pros, et que les vérifications sérieuses, c'est un truc d'amateurs).
[^] # Re: Test Pilot
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse à la dépêche Firefox 47, version de transition. Évalué à 3.
Et pour relancer le même recherche, un peu modifier pour l'affiner ? Il faudrait aussi que ça permette de la récupérer pour l'éditer : ce serait parfait, mais j'ai du mal à imaginer comment un truc pareil pourrait être intégré à la zone d'adresse.
[^] # Re: FAT 32
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Étapes avancées de création d'un live USB. Évalué à 3.
Pas la peine de te fatiguer, comme le mentionne ce tutoriel de façon un peu laconique et simplifiée, Windows est incapable de lire plusieurs partitions sur un périphérique externe, et s'arrêtera à la première. Quoi que tu fasse, toutes les autres seront inaccessibles depuis ce système d'exploitation, il est donc inutile d'essayer de les adapter, ça ne changera rien.
[^] # Re: Installation de GRUB
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Étapes avancées de création d'un live USB. Évalué à 3.
Parfait. Ça installer l'exécutable de GRUB sur la partition que tu as dédiée à cela, puis ça installe dans la MBR un code qui demande au BIOS de l'exécuter.
Ça c'est sûr, il ne les trouvera pas « tout seul ». GRUB n'est pas un outil magique, il fait ce que tu lui dit, et il est certes capable de lire le contenu d'une image de système de fichiers, mais encore faut-il le lui demander.
Tu as effectivement déjà installer GRUB pour UEFI, ce qui a mis l'exécutable correspondant dans
/mnt/EFI, où je suppose que tu avais montée la partition système EFI que tu avais définie et formatée précédemment. Il est normal de devoir utiliser une seconde commande pour installer GRUB pour BIOS (autrement dit GRUB PC), si tu veux que ta clef soit démarrable sur les deux systèmes.Parce que, là où GRUB EFI s'installer sur le système de fichiers d'un partition système EFI (
--efi-directory=/mnt/EFI), GRUB PC s'installer sur un périphérique complet (/dev/sdc).Alors là, ça va dépendre de ce que tu veux faire. À ce niveau de personnalisation de clef USB démarrable, il faut vraiment que tu te familiarise avec le fonctionnement de GRUB et sa configuration.
C'est normal, même si je trouve vraiment affreux de mettre ça dans
…/DISTRIplutôt que le standard…/boot.[^] # Re: FAT 32
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Étapes avancées de création d'un live USB. Évalué à 3.
Non, elle ne sert pas à ça. Vraiment, ça n'a rien à voir.
Parce que, elle installe GRUB en début de partition, dans un espace non utilisé par le système de fichiers, du moins elle le ferait si le système de fichier en question était prévu pour cela, ce qui n'est pas le cas avec FAT. Et que, à moins d'utiliser ensuite un micro-chargeur de démarrage qui va charger ce code, cette installation sera tout simplement inutilisée.
# FAT 32
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Étapes avancées de création d'un live USB. Évalué à 3.
Au fait, pourquoi FAT 32 ? Cette partition n'est pas destinée à être utilisée sous Windows, et il devrait sembler évident que FAT 32 n'est pas le système de fichier idéal pour travailler sous Linux, tant il est déficient (pas de liens symboliques, notamment).
Pour info, si tu avais utilisé quelque chose comme Ext2, ta dernière commande, d'installation de GRUB embarqué dans une partition, aurait correctement fonctionné, bien qu'elle ne serve en pratique à rien du tout.
# Installation de GRUB
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Étapes avancées de création d'un live USB. Évalué à 4.
Non, en tout cas pas pour y embarquer GRUB. J'explique. Pour pouvoir être chargé au démarrage par un BIOS, GRUB doit être écrit quelque part sur le périphérique, de façon linéaire. Traditionnellement, il s'installait ainsi dans l'espace interstitiel situé entre la MBR et la première partition. Ce n'est pas possible avec un partitionnement GPT, où cet espace n'existe pas, c'est pourquoi il faut alors dédier une partition à GRUB, ce que tu as fait.
l existe une autre alternative, qui consiste à l'embarquer dans une zone dédiée à cela dans un système de fichier prévu pour cet usage, c'est à dire un système de fichier qui laisse volontairement sur sa partition une zone qu'il n'utilisera pas. Avec ta commande
grub-install […] /dev/sdc4, c'est ce que tu essaies de faire, sans doute par erreur : installer GRUB dans un espace libre sur/dev/sdc4. Sauf que cette partition est formatée en FAT, et que le système de fichiers FAT n'a pas de zone réservée à cet usage, d'où :Il y a une autre possibilité, qui consiste à installer GRUB comme un fichier, qui peut donc très bien se retrouver sur le périphérique en plusieurs blocs non adjacents, et qui ne pourra donc pas être chargé tel quel par le BIOS. Il faut ensuite déterminer les adresses de ces blocs, et créer un code qui demande au BIOS de charger ces blocs. Cette méthode utilise une liste de blocs, et c'est effectivement moins fiable, donc refusé par GRUB par défaut :
Il faut donc que tu utilises la méthode standard, en demandant à GRUB de s'installer sur ta clef, et non pas sur une partition, avec un
grub-install /dev/sdc. Il trouvera tout seul la partition que tu lui as dédiée, et s'y installera sans problème.# Types de partition
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Étapes avancées de création d'un live USB. Évalué à 4.
Ce ne sont pas des systèmes de fichiers, mais des types de partition, ou plus exactement, des identifiants utilisés par les outils de partitionnement GPT fdisk pour désigner les types de partition suivants :
[^] # Re: Test Pilot
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse à la dépêche Firefox 47, version de transition. Évalué à 5. Dernière modification le 20 juin 2016 à 15:07.
Ce n'est pas cela que je reproche à une zone d'adresse et de recherche unifiée, mais l'impossibilité de rejouer une recherche dans un moteur différent sans avoir à la saisir à nouveau, puisqu'elle aura été remplacée par une URL.
Relis mon second paragraphe, qui répond exactement à ton objection :
[^] # Re: StartEncrypt
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal Petites news dans le monde des autorités de certifications. Évalué à 9.
Je ne sais pas quel est le problème chez toi, mais Let's Encrypt émet sans problème des certificats pour plusieurs noms de domaine, même servis par un serveur qui n'a qu'une seul adresse IP publique.
[^] # Re: Javascript
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal Lettre à mon copain Errol. Évalué à 6.
Pour que ça « aille plus vite » en somme ? C'est amusant, parce qu'en désactivant JavaScript, ça ne va généralement pas plus lentement, plutôt beaucoup, beaucoup plus vite.
[^] # Re: StartEncrypt
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal Petites news dans le monde des autorités de certifications. Évalué à 6.
Et bien ? Le certificat n'est pas en cause là-dedans : une autorité de certification ne garantit qu'une chose, un identité, ici un nom de domaine, pas l'usage qu'on en fait ou la sécurité du serveur sur lequel elle est utilisée.
[^] # Re: StartEncrypt
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal Petites news dans le monde des autorités de certifications. Évalué à 7.
Ah, parce qu'ils n'ont pas utilisé le protocole ACME ? Le boulets…
[^] # Re: Test Pilot
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse à la dépêche Firefox 47, version de transition. Évalué à 8.
C'est ce que je dis, c'est l'alternative ordinaire, moins directe, donc plus lente, plus intrusive en matière de respect de la vie privée, et dépendant d'un service privé unique, avec tout ce que cela implique en matière de SPOF et de concentration de pouvoir. Bref, c'est moins bien, donc autant laisser cela aux béotiens.
[^] # Re: Test Pilot
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse à la dépêche Firefox 47, version de transition. Évalué à 10.
Ça, j'espère vraiment que ce ne sera pas retenu, ou alors de façon facultative, parce que les zones d'adresse et de recherche séparées sont vraiment un avantage de Firefox, particulièrement utile quand on utilise plusieurs moteurs de recherche. Et tout le monde gagnerait à utiliser plusieurs moteurs de recherche, parce que quand on cherche des informations sur la ville de Seattle, il est plus rapide d'aller directement voir la page Wikipédia correspondante, que d'aller demander à DuckDuckGo, pour aller indirectement au même endroit, et ainsi de suite pour la météo à Toulouse (recherche Méteo France), les séances de films à Montpellier (recherche Allociné) ou le plan de la ville de Cannes (recherche OpenStreetMap).
Je vois venir une objection évidente : la zone d'URL peut très bien proposer une recherche sur plusieurs moteurs. Sauf que, une fois la recherche effectuée, on se retrouve sur une page dont l'adresse a remplacé les termes de la recherche, et par conséquent, si on s'aperçoit que la carte OpenStreetMap du village de Saint-Mathieu-en-Cambrousse n'a pas les noms des rues, pour rechercher le même endroit sur Yahoo! Maps, on doit saisir à nouveau la recherche. Alors qu'avec la zone de recherche dédiée, pour relancer la recherche, il suffit de retourner dans celle-ci, qui contient toujours les termes de la recherche, et de la relancer sur un autre moteur.
[^] # Re: Alleluia
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal Du neuf, enfin !. Évalué à 5.
C'est de la vidéo de courte durée en fait, c'est ça ?
[^] # Re: Unix
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal Du neuf, enfin !. Évalué à 4.
Oui, tout comme Windows Millennium Edition était le dernier de la lignée non NT. Ça ne change rien au fait que Mac OS X succède à Mac OS 9, et constitue, commercialement parlant, la version majeure suivante de la lignée de système d'exploitation Mac OS.
# Unix
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal Du neuf, enfin !. Évalué à 10. Dernière modification le 13 juin 2016 à 16:47.
Je ne sais pas trop comment lire ça, vu que ça a l'air à moitié sérieux, mais :
Il me semblait que ce système d'exploitation, qui faisait suite à Mac OS 9, se nommait à l'origine Mac OS X, pour Mac OS, 10e version.
# User Agent
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse à la dépêche Firefox 47, version de transition. Évalué à 5.
C'est sans doute utile pour effectuer des tests, mais l'utilisation principale du changement d'User-Agent n'est-elle pas plutôt le contournement des discriminations ?
[^] # Re: Point de vue d'un "Vieux"
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Utilisation de debian testing. Évalué à 3.
Le retour en arrière, ça peut marcher, mais ce n'est pas du tout prévu. C'est un peu logique en même temps : si à chaque nouvelle version d'un paquet on veille à ce que tout soit bien migré depuis les versions précédentes, dans chaque version on n'a pas du tout veillé à ce que tout soit bien migré depuis une version future, c'est impossible !
[^] # Re: Pour les utilisateurs qui s'y connaissent un minimum
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Utilisation de debian testing. Évalué à 3. Dernière modification le 10 juin 2016 à 15:44.
Ce n'est pas vraiment ça non plus. Les mises à jour n'arrivent pas dans testing par paquets tous les dix jours, elles arrivent continument, avec dix jours (ou cinq, la plupart du temps, en fait) de retard par rapport à leur arrivée dans unstable. Ou plus pour les mises à jour boguées, qui n'entrent pas dans testing tant que ça n'a pas été corrigé, parce que tel est le bug de la distinction entre unstable et testing, bloquer les mise à jour qui introduisent des bogues critiques.
[^] # Re: Daubian toasting
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Utilisation de debian testing. Évalué à 6. Dernière modification le 10 juin 2016 à 15:40.
Pas du tout, ça vient de la Référence du Développeur Debian. Hors période de gel, les paquets envoyés dans unstable y restent un certain temps, qui dépend de la priorité définie par leur mainteneur pour cette mise à jour (10 jours pour un priorité faible, 5 pour une priorité moyenne, 2 pour une priorité élevée).
En ce qui me concerne, ça fait des années que je suis Développeur Debian, et si je suis loin de tout savoir à ce sujet, je suis à peu près au fait du fonctionnement des différentes version (en interne, on parle de distributions, à ne pas confondre avec différentes distributions GNU/Linux…).
Testing est techniquement une distribution à intégration continue différée, hors des périodes de gel. En période de gel, c'est figé en effet.
Unstable est une distribution à intégration continue immédiate, et elle est tout également concernée par le gel, de façon plus subtile : lorsque la testing est gelée, c'est toujours principalement la unstable qui sert recevoir les mises à jour, à ceci près qu'il ne s'agit plus de nouvelles versions mais seulement de corrections de bugs. Par conséquent, on évite d'envoyer de nouvelles versions dans unstable, qui ne seraient en aucun cas acceptées dans testing, et qui bloqueraient les envois de corrections pour des versions antérieures présentes dans testing.
Concrètement, supposons qu'en période de gel, testing contienne autojump 23-2. Arrive autojump version 24, et disons que je l'empaquette pour envoyer un autojump 24-1 dans unstable. On se retrouve alors avec, dans testing, autojump 23-2, et dans unstable, autojump 24-1. Là-dessus, quelqu'un découvre un bug critique sur autojump 23-2, et je prépare un paquet autojump 23-3 corrigeant cela. Problème, je ne peux pas l'envoyer dans unstable, qui contient autojump 24-1 qui est une version supérieure. Ce n'est pas dramatique, je dois alors l'envoyer dans testing-proposed-updates qui est faite pour cela, mais comme c'est un peu agaçant, en pratique on évite ce genre de cas, et, en période de gel, on évite d'envoyer des nouvelles versions dans unstable, préférant utiliser pour cela experimental.
Tout ça pour dire que si unstable est effectivement ce qui s'apparente le plus à une distribution à intégration continue, il ne faut pas non plus s'attendre à ce qu'elle soit toujours mise à jour au même rythme : en période de gel de la testing, son évolution sera également partiellement figée !
[^] # Re: Daubian toasting
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Utilisation de debian testing. Évalué à 3.
Les nouveautés arrivent dans unstable, puis, après dix jours, si aucun bug critique n'y a été détecté, dans testing.
La conséquence évidente, c'est qu'avec unstable, tu as les problèmes et les corrections en direct. Avec testing, tu évites les problèmes qui auront été détectés à temps — pendant les dix jours sus-mentionnés —, mais pas ceux qui ne l'auront pas été, pour lesquelles les corrections seront d'autant plus longues à arriver.
Personnellement, je recommanderais unstable si le but est vraiment de tester Debian pour contribuer à détecter les problèmes (il faut bien que quelqu'un le fasse !), et testing pour un usage quotidien averti (ce n'est pas une distribution stable !), en prenant au besoin des paquets précis d'unstable si ceux-ci apportent des corrections qui ne sont pas encore arrivées dans testing.
[^] # Re: Éléments de réponse
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal authentification et certification de contenu de courriel ?. Évalué à 4.
Dans ce cas ce n'est pas vraiment comparable à une signature, plutôt à un tampon en fait. Et pour le coup, DKIM répond très bien à ce besoin : si on doit pouvoir fournir une indication fiable, vérifiable a posteriori, que tel message provient bien de ton organisation, une signature DKIM fera très bien l'affaire.
Ce n'est peut-être pas une preuve qui sera acceptée sans argumentation par un tribunal, mais avec une expertise qui va bien, ça devrait être tout à fait concluant.
[^] # Re: Un an après, qui a changé l'init par défaut ou est passé à une autre distribution ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse à la dépêche Debian Jessie, 1 an plus tard. Évalué à 8.
Moi.
À noter que sur d'autres systèmes, je suis aussi passé à Debian 8 avec systemd sans problèmes particuliers.
[^] # Re: Tentative :
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal authentification et certification de contenu de courriel ?. Évalué à 2. Dernière modification le 08 juin 2016 à 15:41.
Ça tombe bien, c'est faisable avec PGP, dont le modèle est un sur-ensemble de celui de X.509. En fait, n'importe qui peut être autorité de certification, techniquement parlant j'entends. Administrativement, c'est différent, mais toujours est-il qu'il est tout à fait possible pour des autorités de certification ayant pignon sur rue de signer des clefs PGP, en engageant leur responsabilité comme il se doit (et en faisant des vérifications merdiques, parce que ce sont des pros, et que les vérifications sérieuses, c'est un truc d'amateurs).