C’est 254. On peut aussi jouer avec le délai d’inactivité au bout duquel les têtes sont parquées, avec -S. Chez moi, ce délai est réglé à 5 minutes (-S 60) sur batterie, et à deux heures (-S 244) sur secteur,
À noter que c'est du C++/Qt4, pas mal crade, mais que ça fonctionne normalement bien.
Ça marche très bien chez moi, et après avoir testé sur deux écrans, je confirme : c’est bien exactement ce que je voulais. Du coup je te pardonne volontiers pour le code « pas mal crade ». ;)
Il y a également la prise en charge des vidéos (grâce à libvlc) embarquées par le paquet movie15. Il y a d'autres paquets, mais ils produisent dans le PDF du code qui n'est (était en tout cas) pas encore pris en charge par Poppler quand je travaillais dessus.
En ce qui me concerne, movie15 fait l’affaire. Il est supposé être obsolète et remplacé par media9, mais ce dernier cible explicitement et exclusivement Adobe Reader, alors ce sera sans moi.
En tout cas, merci encore pour ce logiciel dont je vais faire un usage intensif.
Quand on dit « élever dans le domaine publique », qui élève ? l'œuvre elle-même ? Ça ne se dit quasiment jamais !
Je trouve que l’expression « élevée dans le domaine public » est pertinente pour parler d’une œuvre qui entre dans le domaine public suite à la renonciation explicite de son auteur à ses droits (via une license CC-0 par exemple), plutôt que suite à l’expiration passive d’un délai.
Rien à redire sur le diagnostic dans son ensemble, que je partage.
Mais concernant « le langage des styles Bibtex », je recommande vivement de passer à Biblatex, qui permet de mettre en forme les références bibliographiques en utilisant le langage LaTeX lui-même plutôt que le langage spécialisé (et, à ma connaissance, très peu documenté) de Bibtex.
Ce que je trouve qui manque avec Beamer, ce sont les notes pour le présentateur.
Afficher des notes sur l’écran du présentateur est tout-à-fait possible avec Beamer:
\usepackage{pgfpages}
\setbeameroption{notes on second screen=left}
Après, il faut « juste » convaincre le lecteur PDF et/ou le gestionnaire de fenêtre d’afficher correctement le PDF généré, en envoyant la partie gauche (les notes) sur l’écran du portable et la partie droite (les diapositives) sur le vidéo-projecteur. Chez moi, je fais ça avec Xrandr :
Si effectivement on veut neutraliser ce genre d'attaque il suffit d'écrire des règles udev voir ici
pour n'autoriser que ton clavier sur l'usb par exemple (faut penser à mettre la souris aussi peut être), on peut affiner les régles udev pour n'autoriser que le numéro de série que d'un clavier précis et sont branchement sur un port usb précis du système.
Pour ma part, j’ai bricolé quelque chose avec udev, en me basant non pas sur un numéro de série, mais sur le postulat que les périphériques USB d’entrée (claviers, souris et assimilés) « légitimes » sont ceux qui sont déjà branchés lors du démarrage, et seulement ceux-là (je connecte et déconnecte fréquemment des clefs USB à n’importe quel moment une fois le système démarré, mais jamais des claviers et des souris).
Partant de ce principe, à la fin de l’initialisation du système (donc une fois que tous les périphériques « légitimes » ont été détectés), j’ajoute la règle Udev suivante :
qui désactive automatiquement tout nouveau périphérique USB d’entrée, et je recharge Udev — le « truc » est que recharger les règles Udev n’a pas d’effet sur les périphériques déjà connectés, seulement sur ceux qui seront branchés plus tard, donc les périphériques qui étaient déjà là au démarrage ne seront pas touchés. Les autres types de périphériques (clefs USB notamment) ne sont pas affectés non plus, du fait de la sélection sur le SUBSYSTEM=="input".
En gros avoir un nom de domaine dédié pour gérer ces mails àlakon ?
Rien à voir. ;)
Tanguy, engagé dans sa quête pour le respect du RFC 2606, fustigeait juste l’emploi de mon-domaine.com comme exemple de nom de domaine fictif, alors qu’il existe des noms de domaine spécialement réservés pour servir d’exemples dans les documentations.
je me dis que tout se déroule bien jusqu'au RCPT TO et la réponse de mon seveur
Oui. L’établissement de la connexion et le début du dialogue SMTP se font correctement, mais après je ne comprends pas à quoi joue gateway.startcom.org… Une fois le 250 OK reçu en réponse à son RCPT TO, il met fin à la connexion. La terminaison elle-même se fait normalement (FIN, FIN/ACK, ACK).
On dirait que gateway.startcom.org veut juste vérifier que l’adresse est correcte (ce que ton serveur lui apprend en renvoyant le code 2.1.5, signifiant une adresse de destination valide), mais n’a pas l’intention d’envoyer le mail lui-même. D’où sans doute l’intervention de la seconde machine (192.116.242.7), qui est, je suppose, chargée de l’envoi du mail proprement dit. Mais l’intérêt de cette procédure à deux étapes (une première machine qui se connecte juste pour confirmer l’adresse, puis une seconde pour envoyer effectivement le mail) m’échappe…
Concernant la tentative de connexion de la seconde machine, je ne comprends pas ce que viennent faire les requêtes ARP. On dirait que ta machine s’attend à ce que 192.116.242.7 soit dans le même réseau qu’elle-même. Un problème de masque de sous-réseau, ou quelque chose de ce genre ? (Disclaimer : ces problèmes-là dépassent mes compétences, donc je dis peut-être une grosse connerie.)
À ta place, je capturerais le traffic passant par ta carte réseau (tcpdump) pendant une période donnée, pendant laquelle je redemanderais une validation à StartSSL. Puis tu rapatries la capture sur ton poste de travail et tu l’ouvres avec Wireshark (ou un outil du même genre), et tu tentes de comprendre ce qui se passe.
An SMTP server MAY verify that the domain name argument in the EHLO
command actually corresponds to the IP address of the client.
Ça ne correspond qu’aux deux premières lignes de l’exemple que tu donnes :
bonjour je suis $HOSTNAME
dig $HOSTNAME donne IP de la machine
Mais ça ne correspond pas à ta troisième ligne (dig -x $IP donne $HOSTNAME), où tu fais une vérification supplémentaire (un « reverse DNS lookup ») pour savoir si l’IP du client a un enregistrement PTR correspondant au nom annoncé.
S’il n’y avait que XFA… On trouve aussi des PDF conçus par Adobe LiveCycle Designer qui utilisent les « LiveCycle Reader Extensions ». Je ne sais pas exactement ce que ça permet de faire ni comment ça marche, mais ces documents ne sont utilisables avec rien d’autre qu’avec Adobe Reader. Et même pas la version d’Adobe Reader disponible pour GNU/Linux, histoire de rire.
Pour finir le drame a l'air de venir de mupdf qui redirige vers adobe, pas du format lui même.
Non, c’est le document qui contient une page « fallback » (inséré lors de la génération du fichier). Adobe Reader pour GNU/Linux affiche la même page que MuPDF/Evince/Okular/etc. lorsqu’il tombe sur un document dépendant des LiveCycle Reader Extensions.
pas encore réussi à trouver un discours solide face aux gens à convaincre, dur contre "ça va calmos PDF c'est standard regarde la, et de toutes façons Adobe reader est gratos et est compatible Linux, c'est quoi le problème?"
Un argument possible est le fait qu’aux dernières nouvelles (comprendre : la dernière fois que j’ai testé, il y a cinq mois), la version d’Adobe Reader pour Android (le vrai Adobe Reader, fourni par Adobe, officiel et tout et tout) ne permet pas de lire ce genre de « PDF » (il affiche uniquement une page blanche avec le même message que celui rapporté dans ce journal).
À l’heure où tout le monde prédit la fin du PC et l’hégémonie des tablettes et autres smartphones, générer des documents « PDF » illisibles sur une des principales plates-formes mobiles, c’est ballot. Que Adobe continue comme ça, et il vont eux-mêmes saborder la réputation du PDF comme « format qui marche partout ».
À priori, pas grand chose, des biais dans la génération ont été découverts :
Tu parles d’une découverte, les deux premiers sont annoncés blanc sur noir dans le manuel de pwgen(1)…
When used from a non-tty passwords are trivially weak by default (first reported by Solar Designer)
“In addition, for backwards compatibility reasons, when stdout is not a tty and secure password generation mode has not been requested, pwgen will generate less secure passwords”
Phonemes mode has heavy bias and is enabled by default (first reported by Solar Designer)
“The pwgen program generates passwords which are designed to be easily memorized by humans, while being as secure as possible. Human-memorable passwords are never going to be as secure as completely completely random passwords.”
Je viens de constater qu'il est, au moins syntaxiquement, possible de changer la portée du package déclaré en première ligne des fichiers .java.
Avec quel compilateur ?
Chez moi, avec javac 1.7.0, toute tentative d’ajouter un modificateur d’accès devant une déclaration de paquetage se solde par une erreur de compilation :
Seulement lorsque gpg est utilisé en mode de chiffrement symétrique (option -c). En mode asymétrique, le premier algorithme de chiffrement symétrique proposé par défaut est AES256 (CAST5 est aussi proposé par défaut, mais avec une précédence moindre).
Ce sont eux qui codent Xorg depuis 10 ans. Et qui codent Wayland depuis 5 ans, en fait.
Je n’ai jamais dit autre chose.
D'abord, personne ne joue sur les mots.
Si, les développeurs X/Wayland. Sur au moins deux aspects, en fait.
D’abord, puisque la « transparence réseau » de X, au sens où l’entendent les développeurs X/Wayland (j’y reviens tout de suite), n’existe pas, il est évident que tout le monde parle de la possibilité d’utiliser une application X à travers le réseau (ce que les développeurs X/Wayland appellent les « capacités réseau »).
C’est cette fonctionnalité-là que certains utilisent et aimeraient bien voir conservée dans le cœur de Wayland, faire semblant de ne pas le comprendre est grotesque.
Au lieu de répéter à l’envie « X n’est pas network-transparent, il est network-capable » (ce dont tout le monde se fout), répète plutôt à ceux qui ne l’ont pas encore compris « non, Wayland ne sera pas network-capable de base, mais les capacités réseaux pourront être ajoutés par-dessus, donc au final vous aurez la même chose que ce que vous avez déjà maintenant, pas la peine de se plaindre », ce sera plus utile. Et au moins ceux qui se servent actuellement des capacités réseaux de X auront moins l’impression qu’on se fout de leur gueule.
Ensuite, la définition retenue ici de « transparence réseau » n’est pas, à mon sens, la définition habituelle. Pour autant que je sache, dans quelque contexte que ce soit (X non excepté), transparence réseau n’a jamais voulu signifier que l’utilisation du réseau était imperceptible (par rapport à une utilisation locale). Avec une telle définition, et même avec les meilleurs protocoles, la transparence réseau est évidemment un mythe.
Quand quelque chose est « transparent », cela signifie que le support de ce quelque chose n’a pas à être explicitement codé ou activé par l’application. Par exemple, on parle de proxy transparent pour désigner un proxy par lequel passent toutes les communications sans que les clients ne doivent être configurés pour utiliser le proxy (les clients n’ont même pas besoin de savoir que le proxy est là) — mais ça ne veut pas dire que le passage par le proxy ne peut pas induire de latence. Autre exemple, quand j’accède à un fichier à travers le réseau grâce à un montage WebDAV (ou sshfs, ou cifs, ou assimilés), mes applications n’ont pas besoin de supporter l’ouverture de fichiers distants ni même de savoir que le fichier n’est pas local : on dira que l’utilisation du réseau est transparente pour ces applications.
Il en va de même, à mon sens, pour la fameuse « transparence réseau » de X. Je n’ai jamais perçu cette expression comme devant signifier que X devait être aussi performant à travers le réseau qu’en local sans latence additionnelle (les développeurs X/Wayland sont les premiers que j’entends dire ça), mais comme signifiant qu’une application X peut être utilisée à travers le réseau sans que les développeurs de cette application n’aient à implémenter explicitement ce cas d’utilisation.
Ici, l’impression est que les développeurs X/Wayland utilisent une définition beaucoup plus ambitieuse de la « transparence réseau » pour se justifier de ne pas l’implémenter auprès des râleurs, ce qui est absurde pour au moins deux raisons :
— ce n’est pas ce que les râleurs réclament ;
— les développeurs n’ont pas besoin d’une telle justification.
X est network capable, j'dis pas le contraire. Mais pas network-transparent. ;-)
OK, donc la fonctionnalité qui intéresse tout le monde s’appelle « network-capability ». Merci de l’info, on se couchera moins con ce soir, et nos plus plates excuses pour avoir osé appeler ça de la « network transparency ».
Qu’est-ce que ça change au fait que cette fonctionnalité existe et est utilisée dans X actuellement ?
Le fait que ce ne soit pas de la « transparence réseau » n’est pas une explication justifiant sa non-implémentation dans Wayland.
Les développeurs de Wayland ont mille raisons valables de ne pas vouloir implémenter cette fonctionnalité (ne serait-ce que la raison qui tue : ce sont eux qui codent), ils n’ont pas besoin de jouer sur les mots comme ça. Surtout si c’est pour après venir se plaindre des méchants qui racontent des choses fausses sur Internet.
Il ne dit pas que X n'a pas de capacités réseau, ni que personne ne s'en sert.
Il dit que X n'a pas de transparence réseau.
Ça, c’est de la sodomie de drosophile. En quoi le nom de la fonctionnalité change quoi que ce soit ?
OK, X est seulement « network-capable ». En quoi ça répond aux inquiétudes de ceux qui utilisent cette fonctionnalité aujourd’hui et qui apprennent que Wayland n’en disposera pas ?
(Je ne parle pas pour moi, j’ai déjà clairement dit que, bien qu’utilisateur de la « network-capability » de X, elle ne m’était pas indispensable.)
En gros, on a le discours suivant :
« Quoi, on ne pourra pas utiliser Wayland à travers le réseau ? Mais euh, j’aimais bien la transparence réseau de X moi, ça me rend bien service.
— Vous dites n’importe quoi, ça fait dix ans que X n’est plus transparent vis-à-vis du réseau. On peut l’utiliser en réseau (network-capable) mais ce n’est pas transparent.
— Oui, euh, bon d’accord, appelez-ça comme vous voulez, le fait est que ça me rend service de l’utiliser en réseau, c’est dommage de ne pas garder ça dans Wayland.
— Mais non, puisque je vous dis que X n’est déjà plus network-transparent, pourquoi Wayland devrait l’être ? »
Je ne remets pas en cause les choix des développeurs de Wayland : ils estiment préférable de laisser de côté cette fonctionnalité et de la confier à des outils tiers (RDP ou assimilés), je n’ai rien à y redire. Mais à quoi bon prétendre que la fonctionnalité n’existe pas, n’existe plus, ou jouer sur les mots en disant que puisque X n’est plus network-transparent, Wayland n’a pas à être network-capable ?
Non, c'est désactivé par défaut sur les distributions dignes de ce nom
[…]
euh désolé, mais toutes les distib que j'utilise fonctionnent avec ssh -X
Comme quoi, les arguments du genre « c’est comme ça sur toutes les distributions dignes de ce nom » (comprendre : les deux ou trois que je connais) ou « c’est comme ça chez moi » (sous-entendu : donc c’est comme ça partout), c’est bien des « arguments de merde, donc… ».
« Tiens, si je change une ligne dans /etc/ssh/sshd_config, je pourrai utiliser ce programme depuis mon bureau. Pourquoi se priver ? »
et
« Tiens, si je me renseigne sur les protocoles de bureau à distance que je n’ai encore jamais utilisés, que je trouve, installe et configure un serveur d’un tel protocole sur la machine, et que je trouve, installe et configure un client approprié sur mon portable, je pourrai utiliser ce programme à distance depuis mon bureau… Ouais, nan, laisse tomber, ça ne vaut pas le coup. »
Je maintiens : l’avantage de la solution ssh -X est que tout est déjà en place, fournissant un « bonus » à moindre frais dont j’aurais tort de me priver aussi longtemps que c’est possible.
(En supposant bien sûr qu’il y a déjà un serveur SSH qui tourne, ce qui est le cas sur la machine dont je parlais puisque je l’administrais déjà à distance — évidemment, s’il n’y a pas de serveur SSH déjà en place cet avantage disparaît, et tant qu’à faire à devoir installer un serveur pour permettre l’utilisation de programmes graphiques à distance, autant utiliser RDP qui est conçu pour ça.)
avec la flemme de ne pas apprendre juste la nouvelle commande
La flemme d’apprendre à installer et configurer correctement un serveur RDP sur la machine de calcul et un client RDP sur ma propre machine. Rien d’insurmontable certes mais je n’ai pas que ça à faire. L’avantage de la solution ssh -X c’est que tout est déjà en place.
La flemme aussi de négocier auprès du BOFH l’ouverture du port 3389.
Ca s'arrête vite les regrets car faire quelques clic pour activer RDP ou autre
Libre à toi de configurer des serveurs à la va-vite sans comprendre ce que tu actives dans un cliquodrome. Pour ma part, je n’ai pas la prétention d’être un administrateur système mais quand j’installe un serveur quelconque, j’aime m’assurer que je le fais correctement, ou je ne le fais pas.
Ca confirme surtout que le besoin des "utilisateurs" est pas si réél que ça
Dans mon cas je n’ai jamais prétendu le contraire, j’ai explicitement dit que ce n’était pas indispensable. C’est juste un « bonus ». Et oui, c’est un bonus que je regretterai (sans être forcément une perte énorme non plus), qu’est-ce que tu ne comprends pas là-dedans ?
Nous utilisons dans mon labo un programme d’analyse d’image qui ne fonctionne de façon optimale que sous GNU/Linux. Comme personne à part moi n’utilise ce système, j’ai installé une machine sous GNU/Linux dédiée à ce programme.
Mes collègues vont faire leurs analyses directement sur la machine. Moi, je les fais sans quitter mon propre poste, à travers ssh -X. Tant pis si c’est « tellement années 80 », ça marche.
Est-ce que c’est indispensable ? Certes non, sûrement pas assez en tout cas pour que j’installe un serveur RDP ou toute autre solution de ce genre le jour où un simple ssh -X ne fonctionnera plus : je ferai les dix mètres qui me séparent de la machine de calcul, comme mes collègues le font déjà. C’est juste très pratique, et je regretterai la disparition de cette possibilité.
[^] # Re: Ne jamais attribuer à la malveillance ce que la stupidité suffit à expliquer.
Posté par gouttegd . En réponse au journal Obsolescence programmée ou pas ?. Évalué à 2.
C’est 254. On peut aussi jouer avec le délai d’inactivité au bout duquel les têtes sont parquées, avec -S. Chez moi, ce délai est réglé à 5 minutes (-S 60) sur batterie, et à deux heures (-S 244) sur secteur,
[^] # Re: Aide du présentateur
Posté par gouttegd . En réponse au journal Le HTML (epub3) peut il détrôner latex (surtout beamer) ?. Évalué à 3.
Ça marche très bien chez moi, et après avoir testé sur deux écrans, je confirme : c’est bien exactement ce que je voulais. Du coup je te pardonne volontiers pour le code « pas mal crade ». ;)
En ce qui me concerne, movie15 fait l’affaire. Il est supposé être obsolète et remplacé par media9, mais ce dernier cible explicitement et exclusivement Adobe Reader, alors ce sera sans moi.
En tout cas, merci encore pour ce logiciel dont je vais faire un usage intensif.
[^] # Re: Aide du présentateur
Posté par gouttegd . En réponse au journal Le HTML (epub3) peut il détrôner latex (surtout beamer) ?. Évalué à 3.
Je teste ça dès ce soir avec un deuxième écran, mais ça m’a tout l’air d’être exactement ce que je cherchais depuis longtemps.
Merci !
[^] # Re: Ascencion
Posté par gouttegd . En réponse au journal Tintin tombera-t-il un jour dans le domaine public ?. Évalué à 2.
Je trouve que l’expression « élevée dans le domaine public » est pertinente pour parler d’une œuvre qui entre dans le domaine public suite à la renonciation explicite de son auteur à ses droits (via une license CC-0 par exemple), plutôt que suite à l’expiration passive d’un délai.
[^] # Re: Langage
Posté par gouttegd . En réponse au journal Le HTML (epub3) peut il détrôner latex (surtout beamer) ?. Évalué à 3.
Rien à redire sur le diagnostic dans son ensemble, que je partage.
Mais concernant « le langage des styles Bibtex », je recommande vivement de passer à Biblatex, qui permet de mettre en forme les références bibliographiques en utilisant le langage LaTeX lui-même plutôt que le langage spécialisé (et, à ma connaissance, très peu documenté) de Bibtex.
[^] # Re: Aide du présentateur
Posté par gouttegd . En réponse au journal Le HTML (epub3) peut il détrôner latex (surtout beamer) ?. Évalué à 7.
Afficher des notes sur l’écran du présentateur est tout-à-fait possible avec Beamer:
Après, il faut « juste » convaincre le lecteur PDF et/ou le gestionnaire de fenêtre d’afficher correctement le PDF généré, en envoyant la partie gauche (les notes) sur l’écran du portable et la partie droite (les diapositives) sur le vidéo-projecteur. Chez moi, je fais ça avec Xrandr :
ou encore, en tirant profit du fait que l’écran de mon portable a une résolution de 1600x900 :
pour afficher les notes et la diapositive en cours sur l’écran interne, et la diapositive sur l’écran externe.
[^] # Re: JRO ?
Posté par gouttegd . En réponse au journal JRO, le système d'exploitation n°1 en 2013. Évalué à 2.
De rien.
[^] # Re: Non il ne faut jamais faire confiance à personne
Posté par gouttegd . En réponse au message USB Keyboard. Évalué à 7.
Pour ma part, j’ai bricolé quelque chose avec udev, en me basant non pas sur un numéro de série, mais sur le postulat que les périphériques USB d’entrée (claviers, souris et assimilés) « légitimes » sont ceux qui sont déjà branchés lors du démarrage, et seulement ceux-là (je connecte et déconnecte fréquemment des clefs USB à n’importe quel moment une fois le système démarré, mais jamais des claviers et des souris).
Partant de ce principe, à la fin de l’initialisation du système (donc une fois que tous les périphériques « légitimes » ont été détectés), j’ajoute la règle Udev suivante :
qui désactive automatiquement tout nouveau périphérique USB d’entrée, et je recharge Udev — le « truc » est que recharger les règles Udev n’a pas d’effet sur les périphériques déjà connectés, seulement sur ceux qui seront branchés plus tard, donc les périphériques qui étaient déjà là au démarrage ne seront pas touchés. Les autres types de périphériques (clefs USB notamment) ne sont pas affectés non plus, du fait de la sélection sur le SUBSYSTEM=="input".
[^] # Re: Deux trois choses
Posté par gouttegd . En réponse à la dépêche Héberger son courriel. Évalué à 3.
Rien à voir. ;)
Tanguy, engagé dans sa quête pour le respect du RFC 2606, fustigeait juste l’emploi de mon-domaine.com comme exemple de nom de domaine fictif, alors qu’il existe des noms de domaine spécialement réservés pour servir d’exemples dans les documentations.
[^] # Re: même pas un petit indice ?
Posté par gouttegd . En réponse au message [RESOLU] Postfix : lost connection after RCPT from gateway.startcom.org. Évalué à 3.
Oui. L’établissement de la connexion et le début du dialogue SMTP se font correctement, mais après je ne comprends pas à quoi joue gateway.startcom.org… Une fois le 250 OK reçu en réponse à son RCPT TO, il met fin à la connexion. La terminaison elle-même se fait normalement (FIN, FIN/ACK, ACK).
On dirait que gateway.startcom.org veut juste vérifier que l’adresse est correcte (ce que ton serveur lui apprend en renvoyant le code 2.1.5, signifiant une adresse de destination valide), mais n’a pas l’intention d’envoyer le mail lui-même. D’où sans doute l’intervention de la seconde machine (192.116.242.7), qui est, je suppose, chargée de l’envoi du mail proprement dit. Mais l’intérêt de cette procédure à deux étapes (une première machine qui se connecte juste pour confirmer l’adresse, puis une seconde pour envoyer effectivement le mail) m’échappe…
Concernant la tentative de connexion de la seconde machine, je ne comprends pas ce que viennent faire les requêtes ARP. On dirait que ta machine s’attend à ce que 192.116.242.7 soit dans le même réseau qu’elle-même. Un problème de masque de sous-réseau, ou quelque chose de ce genre ? (Disclaimer : ces problèmes-là dépassent mes compétences, donc je dis peut-être une grosse connerie.)
[^] # Re: même pas un petit indice ?
Posté par gouttegd . En réponse au message [RESOLU] Postfix : lost connection after RCPT from gateway.startcom.org. Évalué à 3.
À ta place, je capturerais le traffic passant par ta carte réseau (tcpdump) pendant une période donnée, pendant laquelle je redemanderais une validation à StartSSL. Puis tu rapatries la capture sur ton poste de travail et tu l’ouvres avec Wireshark (ou un outil du même genre), et tu tentes de comprendre ce qui se passe.
[^] # Re: Deux trois choses
Posté par gouttegd . En réponse à la dépêche Héberger son courriel. Évalué à 3.
Ça ne correspond qu’aux deux premières lignes de l’exemple que tu donnes :
Mais ça ne correspond pas à ta troisième ligne (
dig -x $IP donne $HOSTNAME), où tu fais une vérification supplémentaire (un « reverse DNS lookup ») pour savoir si l’IP du client a un enregistrement PTR correspondant au nom annoncé.[^] # Re: C'est pas standard, mais c'est pas fermé non plus
Posté par gouttegd . En réponse au journal C'est un scandale !. Évalué à 4.
S’il n’y avait que XFA… On trouve aussi des PDF conçus par Adobe LiveCycle Designer qui utilisent les « LiveCycle Reader Extensions ». Je ne sais pas exactement ce que ça permet de faire ni comment ça marche, mais ces documents ne sont utilisables avec rien d’autre qu’avec Adobe Reader. Et même pas la version d’Adobe Reader disponible pour GNU/Linux, histoire de rire.
Non, c’est le document qui contient une page « fallback » (inséré lors de la génération du fichier). Adobe Reader pour GNU/Linux affiche la même page que MuPDF/Evince/Okular/etc. lorsqu’il tombe sur un document dépendant des LiveCycle Reader Extensions.
[^] # Re: Fuck Adobe
Posté par gouttegd . En réponse au journal C'est un scandale !. Évalué à 10.
Un argument possible est le fait qu’aux dernières nouvelles (comprendre : la dernière fois que j’ai testé, il y a cinq mois), la version d’Adobe Reader pour Android (le vrai Adobe Reader, fourni par Adobe, officiel et tout et tout) ne permet pas de lire ce genre de « PDF » (il affiche uniquement une page blanche avec le même message que celui rapporté dans ce journal).
À l’heure où tout le monde prédit la fin du PC et l’hégémonie des tablettes et autres smartphones, générer des documents « PDF » illisibles sur une des principales plates-formes mobiles, c’est ballot. Que Adobe continue comme ça, et il vont eux-mêmes saborder la réputation du PDF comme « format qui marche partout ».
[^] # Re: Que vaut un mot de passe comme ceux de pwgen ?
Posté par gouttegd . En réponse au journal La proche fin des mots de passe. Évalué à 2.
Tu parles d’une découverte, les deux premiers sont annoncés blanc sur noir dans le manuel de pwgen(1)…
“In addition, for backwards compatibility reasons, when stdout is not a tty and secure password generation mode has not been requested, pwgen will generate less secure passwords”
“The pwgen program generates passwords which are designed to be easily memorized by humans, while being as secure as possible. Human-memorable passwords are never going to be as secure as completely completely random passwords.”
# Ce n’est pas supposé être possible…
Posté par gouttegd . En réponse au message private package com.monsuperpackage. Évalué à 3.
Avec quel compilateur ?
Chez moi, avec javac 1.7.0, toute tentative d’ajouter un modificateur d’accès devant une déclaration de paquetage se solde par une erreur de compilation :
C’est conforme à la spécification du langage Java, qui ne semble pas admettre la possibilité d’ajouter un modificateur d’accès et précise d’ailleurs qu’un paquetage est toujours accessible.
[^] # Re: Bitcoin :)
Posté par gouttegd . En réponse au journal Fermeture de Silk Road par le FBI. Évalué à 3.
Seulement lorsque gpg est utilisé en mode de chiffrement symétrique (option
-c). En mode asymétrique, le premier algorithme de chiffrement symétrique proposé par défaut est AES256 (CAST5 est aussi proposé par défaut, mais avec une précédence moindre).[^] # Re: OSEF
Posté par gouttegd . En réponse au journal Le mythe de la transparence réseau. Évalué à 8.
Je n’ai jamais dit autre chose.
Si, les développeurs X/Wayland. Sur au moins deux aspects, en fait.
D’abord, puisque la « transparence réseau » de X, au sens où l’entendent les développeurs X/Wayland (j’y reviens tout de suite), n’existe pas, il est évident que tout le monde parle de la possibilité d’utiliser une application X à travers le réseau (ce que les développeurs X/Wayland appellent les « capacités réseau »).
C’est cette fonctionnalité-là que certains utilisent et aimeraient bien voir conservée dans le cœur de Wayland, faire semblant de ne pas le comprendre est grotesque.
Au lieu de répéter à l’envie « X n’est pas network-transparent, il est network-capable » (ce dont tout le monde se fout), répète plutôt à ceux qui ne l’ont pas encore compris « non, Wayland ne sera pas network-capable de base, mais les capacités réseaux pourront être ajoutés par-dessus, donc au final vous aurez la même chose que ce que vous avez déjà maintenant, pas la peine de se plaindre », ce sera plus utile. Et au moins ceux qui se servent actuellement des capacités réseaux de X auront moins l’impression qu’on se fout de leur gueule.
Ensuite, la définition retenue ici de « transparence réseau » n’est pas, à mon sens, la définition habituelle. Pour autant que je sache, dans quelque contexte que ce soit (X non excepté), transparence réseau n’a jamais voulu signifier que l’utilisation du réseau était imperceptible (par rapport à une utilisation locale). Avec une telle définition, et même avec les meilleurs protocoles, la transparence réseau est évidemment un mythe.
Quand quelque chose est « transparent », cela signifie que le support de ce quelque chose n’a pas à être explicitement codé ou activé par l’application. Par exemple, on parle de proxy transparent pour désigner un proxy par lequel passent toutes les communications sans que les clients ne doivent être configurés pour utiliser le proxy (les clients n’ont même pas besoin de savoir que le proxy est là) — mais ça ne veut pas dire que le passage par le proxy ne peut pas induire de latence. Autre exemple, quand j’accède à un fichier à travers le réseau grâce à un montage WebDAV (ou sshfs, ou cifs, ou assimilés), mes applications n’ont pas besoin de supporter l’ouverture de fichiers distants ni même de savoir que le fichier n’est pas local : on dira que l’utilisation du réseau est transparente pour ces applications.
Il en va de même, à mon sens, pour la fameuse « transparence réseau » de X. Je n’ai jamais perçu cette expression comme devant signifier que X devait être aussi performant à travers le réseau qu’en local sans latence additionnelle (les développeurs X/Wayland sont les premiers que j’entends dire ça), mais comme signifiant qu’une application X peut être utilisée à travers le réseau sans que les développeurs de cette application n’aient à implémenter explicitement ce cas d’utilisation.
Ici, l’impression est que les développeurs X/Wayland utilisent une définition beaucoup plus ambitieuse de la « transparence réseau » pour se justifier de ne pas l’implémenter auprès des râleurs, ce qui est absurde pour au moins deux raisons :
— ce n’est pas ce que les râleurs réclament ;
— les développeurs n’ont pas besoin d’une telle justification.
[^] # Re: OSEF
Posté par gouttegd . En réponse au journal Le mythe de la transparence réseau. Évalué à 0. Dernière modification le 01 octobre 2013 à 10:54.
Oh putain t’es LOURD à pas comprendre. ;)
OK, donc la fonctionnalité qui intéresse tout le monde s’appelle « network-capability ». Merci de l’info, on se couchera moins con ce soir, et nos plus plates excuses pour avoir osé appeler ça de la « network transparency ».
Qu’est-ce que ça change au fait que cette fonctionnalité existe et est utilisée dans X actuellement ?
Le fait que ce ne soit pas de la « transparence réseau » n’est pas une explication justifiant sa non-implémentation dans Wayland.
Les développeurs de Wayland ont mille raisons valables de ne pas vouloir implémenter cette fonctionnalité (ne serait-ce que la raison qui tue : ce sont eux qui codent), ils n’ont pas besoin de jouer sur les mots comme ça. Surtout si c’est pour après venir se plaindre des méchants qui racontent des choses fausses sur Internet.
[^] # Re: OSEF
Posté par gouttegd . En réponse au journal Le mythe de la transparence réseau. Évalué à 5.
Ça, c’est de la sodomie de drosophile. En quoi le nom de la fonctionnalité change quoi que ce soit ?
OK, X est seulement « network-capable ». En quoi ça répond aux inquiétudes de ceux qui utilisent cette fonctionnalité aujourd’hui et qui apprennent que Wayland n’en disposera pas ?
(Je ne parle pas pour moi, j’ai déjà clairement dit que, bien qu’utilisateur de la « network-capability » de X, elle ne m’était pas indispensable.)
En gros, on a le discours suivant :
« Quoi, on ne pourra pas utiliser Wayland à travers le réseau ? Mais euh, j’aimais bien la transparence réseau de X moi, ça me rend bien service.
— Vous dites n’importe quoi, ça fait dix ans que X n’est plus transparent vis-à-vis du réseau. On peut l’utiliser en réseau (network-capable) mais ce n’est pas transparent.
— Oui, euh, bon d’accord, appelez-ça comme vous voulez, le fait est que ça me rend service de l’utiliser en réseau, c’est dommage de ne pas garder ça dans Wayland.
— Mais non, puisque je vous dis que X n’est déjà plus network-transparent, pourquoi Wayland devrait l’être ? »
Je ne remets pas en cause les choix des développeurs de Wayland : ils estiment préférable de laisser de côté cette fonctionnalité et de la confier à des outils tiers (RDP ou assimilés), je n’ai rien à y redire. Mais à quoi bon prétendre que la fonctionnalité n’existe pas, n’existe plus, ou jouer sur les mots en disant que puisque X n’est plus network-transparent, Wayland n’a pas à être network-capable ?
[^] # Re: OSEF
Posté par gouttegd . En réponse au journal Le mythe de la transparence réseau. Évalué à 1.
[…]
Comme quoi, les arguments du genre « c’est comme ça sur toutes les distributions dignes de ce nom » (comprendre : les deux ou trois que je connais) ou « c’est comme ça chez moi » (sous-entendu : donc c’est comme ça partout), c’est bien des « arguments de merde, donc… ».
[^] # Re: OSEF
Posté par gouttegd . En réponse au journal Le mythe de la transparence réseau. Évalué à 1.
Et tu ne vois vraiment pas de différence entre :
« Tiens, si je change une ligne dans /etc/ssh/sshd_config, je pourrai utiliser ce programme depuis mon bureau. Pourquoi se priver ? »
et
« Tiens, si je me renseigne sur les protocoles de bureau à distance que je n’ai encore jamais utilisés, que je trouve, installe et configure un serveur d’un tel protocole sur la machine, et que je trouve, installe et configure un client approprié sur mon portable, je pourrai utiliser ce programme à distance depuis mon bureau… Ouais, nan, laisse tomber, ça ne vaut pas le coup. »
Je maintiens : l’avantage de la solution ssh -X est que tout est déjà en place, fournissant un « bonus » à moindre frais dont j’aurais tort de me priver aussi longtemps que c’est possible.
(En supposant bien sûr qu’il y a déjà un serveur SSH qui tourne, ce qui est le cas sur la machine dont je parlais puisque je l’administrais déjà à distance — évidemment, s’il n’y a pas de serveur SSH déjà en place cet avantage disparaît, et tant qu’à faire à devoir installer un serveur pour permettre l’utilisation de programmes graphiques à distance, autant utiliser RDP qui est conçu pour ça.)
[^] # Re: OSEF
Posté par gouttegd . En réponse au journal Le mythe de la transparence réseau. Évalué à 3.
Je n‘avais pas pensé à ça. >_<
(Et m*rde, à force d’en parler je vais finir par avoir envie d’essayer… C’est malin !)
[^] # Re: OSEF
Posté par gouttegd . En réponse au journal Le mythe de la transparence réseau. Évalué à 1.
La flemme d’apprendre à installer et configurer correctement un serveur RDP sur la machine de calcul et un client RDP sur ma propre machine. Rien d’insurmontable certes mais je n’ai pas que ça à faire. L’avantage de la solution ssh -X c’est que tout est déjà en place.
La flemme aussi de négocier auprès du BOFH l’ouverture du port 3389.
Libre à toi de configurer des serveurs à la va-vite sans comprendre ce que tu actives dans un cliquodrome. Pour ma part, je n’ai pas la prétention d’être un administrateur système mais quand j’installe un serveur quelconque, j’aime m’assurer que je le fais correctement, ou je ne le fais pas.
Dans mon cas je n’ai jamais prétendu le contraire, j’ai explicitement dit que ce n’était pas indispensable. C’est juste un « bonus ». Et oui, c’est un bonus que je regretterai (sans être forcément une perte énorme non plus), qu’est-ce que tu ne comprends pas là-dedans ?
[^] # Re: OSEF
Posté par gouttegd . En réponse au journal Le mythe de la transparence réseau. Évalué à 3. Dernière modification le 29 septembre 2013 à 16:19.
Pour illustrer, mon cas d’utilisation :
Nous utilisons dans mon labo un programme d’analyse d’image qui ne fonctionne de façon optimale que sous GNU/Linux. Comme personne à part moi n’utilise ce système, j’ai installé une machine sous GNU/Linux dédiée à ce programme.
Mes collègues vont faire leurs analyses directement sur la machine. Moi, je les fais sans quitter mon propre poste, à travers ssh -X. Tant pis si c’est « tellement années 80 », ça marche.
Est-ce que c’est indispensable ? Certes non, sûrement pas assez en tout cas pour que j’installe un serveur RDP ou toute autre solution de ce genre le jour où un simple ssh -X ne fonctionnera plus : je ferai les dix mètres qui me séparent de la machine de calcul, comme mes collègues le font déjà. C’est juste très pratique, et je regretterai la disparition de cette possibilité.