Pour accéder à wallabag via HTTPS, c'est le port :443 qu'il faut rediriger vers l'IP du NAS. Ce dernier doit évidemment écouter en HTTPS, c'est à dire que son serveur web doit avoir des certificats SSL ad-hoc, par exemple générés avec Let's Encrypt.
Activer la fonction DMZ, c'est plus une augmentation de la surface d'attaque de ton NAS qu'autre chose. Sauf si c'est nécessaire, je déconseille.
Genre:
1. convertir les documents au format texte, puis avec des libs de NLP
2. faire la tokenization
3. récupérer les stems
4. calculer les distances entre les documents
C'est facile à scripter, et te permet de faire un PoC rapidement. Une petite interface web ad hoc n'est sans doute pas compliquée à faire, ou tout comme le scan automatique de documents stockés dans un espace dédié sur des disques réseaux partagés. Le support d'autres langues que l'anglais dépend fortement de la lib NLP que tu utilises.
Sinon, vaguement connexe, il y a prochainement un webinaire sur le text-mining et les brevets.
Fais-moisigne si tu as envie d'en savoir plus. J'ai fréquenté pendant longtemps le monde de la recherche en suisse, et la thématique m'intéresse beaucoup: ça peut être intéressant d'en parler.
Je suis très curieux des éventuelles suites, et je pense ne pas être le seul :)
Dans le domaine que je connais le mieux (la modélisation moléculaire en Suisse), soit les codes sont vivants et développés, soit ils sont obsolètes très rapidement. La TMA n'a donc pas vraiment de place et n'est jamais budgetisée. Par conséquent, le développement d'un logiciel scientifique impose donc une double contrainte d’adéquation scientifique et de flexibilité dans la durée. Il faut donc travailler au bon niveau d'abstraction et gérer avec le plus grand soin la dette technique. Sur ces deux points, la plupart des 'décideurs pressés' que j'ai croisé dans le monde scientifique académique (hors informatique) sont aussi notoirement incompétents que la plupart de leurs étudiants en thèse. Les objectifs des premiers sont de plus en plus d'avoir des sous et de bien se faire voir de leur hiérarchie, pas de faire avancer la recherche à travers de la mise à disposition de leurs outils/méthodes. Les objectifs des seconds sont de devenir le plus rapidement possible comme les premiers. Dans un cas comme dans l'autre, le premier objectif est la carrière personnelle.
Les très rares pros à la fois dans un domaine scientifique précis et en informatique, faute de possibilité de carrière et de reconnaissance dans le monde académique, préfèrent pour la plupart travailler dans le privé où les conditions sont bien plus avantageuses, lorsqu'ils ne sont pas jetés hors du monde académique parce qu'"on" ne veut pas comprendre pas de quoi et-ce qu'ils parlent et pourquoi est-ce que c'est important. Or, dans ce domaine: pas outils, pas de science (au sens de développement méthodologique), au mieux du service et de la sous-traitance qu'on nomme pudiquement "collaboration" et qui permet de réseauter pour assouvir les ambitions des égos.
Au final, c'est donc la science qui est en panne, faute d'outils fiables et de possibilité d'instaurer une dynamique de partage mutuellement gagnant-gagnant au sein de la communauté académique. YMMV, comme on dit, et heureusement ça a tendance à changer doucement, justement avec des mouvements comme Software Carpentry. Il y a du boulot.
Je suis dans la même situation que toi, et je crois que ce problème est très courant.
Le code informatique utilisé dans la recherche n'a souvent de financement que pour son développement initial, lequel se fait premièrement - souvent "seulement" - avec pour but d'en tirer une publication. La maintenance du code, la correction de bug, les modifications parfois nécessaires lorsque des dépendances changent, ne sont généralement pas considérées. Dès lors, les codes meurent assez rapidement. Cette tendance est si problématique qu'émergent des mouvements structurés pour la combattre, comme Software Carpentry, qui est justement en train de proposer un petit guide intéressant à l'usage des chercheurs.
En pratique, c'est à ceux qui ont besoin d'utiliser ce code de s'occuper d'en assurer la maintenance, et pas à toi, quand bien même c'est un peu "ton bébé". Surtout si tu as quitté le monde de la recherche, je te conseille de ne perd pas ton temps à essayer de t'en occuper: ça dédouanerait les utilisateurs de toutes responsabilités, ce qui contribuerait à pérenniser le système en place qui doit changer.
Aucune idée d'où est passé la spec IPOT, mais ça me rappelle un trou noir dans lequel était tombé la-rache.com, avant de ressortir sur un dépôt github. Sans doute une idée à suivre pour IPOT, quand on le retrouvera, c'est à dire hier.
Je crois avoir compris que ce qu'il souhaite, le monsieur, c'est un compte à rebours associé à une interface "graphique". GRUB ne permet pas de proposer un choix "graphique", si ?
Telegram fait en effet du multi-device, mais pas lorsque le chiffrement de bout-en-bout est activé. Par défaut, il ne l'est pas. Pour qu'il le soit, il faut lancer un secret chat. Le client officiel Telegram Desktop n'implémentepas ces secret chats, au contraire d'autres clients - par exemple l'autre client officiel sur macOS Telegram Messenger (deux clients officiels? WTF?), lui, le propose. Le support est donc aléatoire. C'est pour cela que la réputation de "sécurité/confidentialité" de Telegram est passablement surfaite: beaucoup pensent que "par défaut", c'est chiffré entre les terminaux, alors que ça ne l'est que du terminal au serveur, que ce dernier voit tout passer, et que la plupart des utilisateurs n'ont même jamais vu l'option "secret chat"… bref…
Dans le cas du chiffrement de bout-en-bout implémenté dans ces secret chats, il n'y a pas de synchronisation possible entre les clients Telegram d'un même utilisateur, donc pas d'historique unifié entre les terminaux. En effet, les clés de chiffrements sur lesquelles se basent le chiffrement de bout-en-bout ne sont physiquement que sur les terminaux en cours de communication. Or, pour qu'une synchronisation a posteriori soit possible entre plusieurs terminaux d'un même utilisateur, il faudrait que ces clés soient partagées entre eux. Si les deux ne sont pas online en même temps, il faut donc également qu'elles soient stockées, ce qui est contradictoire avec leur caractère éphémères qu'impose la PFS. Comme elles ne sont stockées nulle part, elles sont impossible à synchroniser, et donc pas d'historique multi-device..
La solution apportée par Openwhisper Systems avec Signal est très élégante. L'implémentation proposée par WhatsApp est également un joli contournement du problème: le chat est toujours chiffré de bout-en-tout, et l'illusion du multi-device est donné par le fait que ton ordi avec WhatsApp Desktop ou équivalent se connecte à ton téléphone qui centralise chiffrement et historique. Du coup, tu as le beurre (le chiffrement de bout-en-bout) et l'argent du beurre (la synchronisation de l'historique, même si c'est une illusion puisqu'il ne quitte jamais ton téléphone).
Bref, Telegram c'est pas trop ça, en tout cas sur cet aspect là qui n'est sans doute pas qu'un détail pour beaucoup ici, par rapport à Signal ou surtout WhatsApp qui cumule cet avantage avec d'autres, comme le fait d'avoir une base d'utilisateur considérable.
Je pense qu'on sera pas mal à partager ton point de vu.
Pour ma part, je complémente mon serveur XMPP auto-hébergé avec WhatsApp. Je trouve assez révélateur de constater que la plupart des personnes qui peuvent me contacter avec l'un ou avec l'autre échangent avec moi plus facilement via WhatsApp que via XMPP, quand bien même les clients sont installés sur leurs ordis/téléphones. N'utiliser qu'un seul service c'est s'en rendre dépendant, mais aussi minimiser la charge cognitive nécessaire à l'usage.
Du coup, en l'état mon serveur XMPP devient presque inutile, sauf comme fallback au besoin. Or, il existe des alternatives qui me sembleraient très bien jouer ce rôle d'appoint, sans nécessiter l'administration d'un serveur XMPP. Je pense par exemple à Tox, et en particulier à qTox (sur le desktop) et Antox (sur le mobile). Seul bémol: il n'y a pour l'instant aucune gestion du multi-device (donc aucun historique partagé ni gestion de la présence unifiée), ni PFS - et ça, c'est pour moi presque plus gênant et surtout incompréhensible. Heureusement, l'implémentation de l'un et de l'autre sont en route. Il faut juste être patient…
… et pendant ce temps, les autres solutions progressent aussi…
Pour le coup, Telegram a accès au métadonnées (comme WhatsApp), mais le chiffrement de bout-en-bout est carrément planqué, pas disponible sur tous les clients, et surtout pas synchronisé entre eux. Dans la pratique, il n'est donc pas vraiment utilisable sauf à consentir à une gène à l'utilisation. WhatsApp me semble du coup être un meilleur compromis.
À noter que c'est justement dans le cadre d'un partenariat avec OpenWhisper Systems que WhatsApp a pu déployer son chiffrement de bout-en-bout. L'article de l'EFF à ce sujet est très intéressant à lire.
La gestion du multi-device est assez inattendue et je la trouve assez élégante: il est possible d'utiliser un client officiel sur son ordinateur (il existe des alternatives ici ou là), qui communiquent avec le téléphone sur lequel WhatsApp est installé, ce dernier restant en charge de toutes les opérations de chiffrement/déchiffrement. Bien sûr, il faut que le téléphone soit allumé et connecté, en contrepartie de quoi il est possible de faire du chiffrement de bout en bout tout en gardant un historique unifié et accessible depuis tous les terminaux.
Signal, d'OWS, fonctionne logiquement de la même façon. En attendant qu'il soit interopérable (on peut rêver, non?)…
La possibilité d'interception ne serait-elle pas la même pour XMPP ? OK, OTR limite considérablement les risques, en tout cas si on vérifie les fingerprints sérieusement, sauf si on n'a qu'un terminal mobile et qu'il est MITMé dès la première connexion…
Tu as aussi WooCommerce, qui est un plugin pour le classique Wordpress.
Suivant le positionnement de ton amie, il y a aussi le très connu alittlemarket, qui est une filiale d'Etsy. Il y a potentiellement beaucoup d'inconvénients à passer par un site dans ce genre, mais suivant les volumes de ventes qu'elle envisage de faire, ça peut être une option à considérer.
Le lien entre electron et chromium, et donc entre tofino est chromium, est perçue par certains comme un signe inquiétant concernant les principes et les bases techniques historiques de Mozilla.
Vraiment très sympa, ce projet. Utilisateur de tt-rss, j'apprécie énormément les raccourcis claviers qui permettent par exemple de passer d'un article à l'autre sans avoir à toucher la souris. C'est le genre de chose qui enlarge tellement la productivity qu'il est difficile de s'en passer :)
Ces problèmes que tu décris m'évoquent Ricochet, mais ce dernier n'a rien à voir avec XMPP. C'est un système de messagerie instantanée anonyme et chiffré de bout en bout qui protège aussi bien le contenu que les métadonnées. Pour ce faire, il passe par TOR, et remplace l'identification par nom d'utilisateur / nom de serveur par le nom d'un service caché instancié en parallèle du client. La question du passage du NAT est donc déléguée à TOR, ainsi que le changement d'adresse IP également.
[^] # Re: NLP ?
Posté par aurel (site web personnel, Mastodon) . En réponse au message logiciel de détection de plagiat. Évalué à 2.
À noter un article qui liste 5 outils de détection de plagiat sur ZDNet.
[^] # Re: dmz ou pas dmz, ca c'est la question
Posté par aurel (site web personnel, Mastodon) . En réponse au message Serveur auto-hébergement derrière une Freebox. Évalué à 3.
Pour accéder à wallabag via HTTPS, c'est le port :443 qu'il faut rediriger vers l'IP du NAS. Ce dernier doit évidemment écouter en HTTPS, c'est à dire que son serveur web doit avoir des certificats SSL ad-hoc, par exemple générés avec Let's Encrypt.
Activer la fonction DMZ, c'est plus une augmentation de la surface d'attaque de ton NAS qu'autre chose. Sauf si c'est nécessaire, je déconseille.
# NLP ?
Posté par aurel (site web personnel, Mastodon) . En réponse au message logiciel de détection de plagiat. Évalué à 3. Dernière modification le 01 octobre 2016 à 09:22.
Genre:
1. convertir les documents au format texte, puis avec des libs de NLP
2. faire la tokenization
3. récupérer les stems
4. calculer les distances entre les documents
cf. https://stackoverflow.com/questions/8897593/similarity-between-two-text-documents.
C'est facile à scripter, et te permet de faire un PoC rapidement. Une petite interface web ad hoc n'est sans doute pas compliquée à faire, ou tout comme le scan automatique de documents stockés dans un espace dédié sur des disques réseaux partagés. Le support d'autres langues que l'anglais dépend fortement de la lib NLP que tu utilises.
Sinon, vaguement connexe, il y a prochainement un webinaire sur le text-mining et les brevets.
Fais-moi signe si tu as envie d'en savoir plus. J'ai fréquenté pendant longtemps le monde de la recherche en suisse, et la thématique m'intéresse beaucoup: ça peut être intéressant d'en parler.
[^] # Re: Codes de recherche orphelins
Posté par aurel (site web personnel, Mastodon) . En réponse au message Passer le flambeau. Évalué à 3.
Je suis très curieux des éventuelles suites, et je pense ne pas être le seul :)
Dans le domaine que je connais le mieux (la modélisation moléculaire en Suisse), soit les codes sont vivants et développés, soit ils sont obsolètes très rapidement. La TMA n'a donc pas vraiment de place et n'est jamais budgetisée. Par conséquent, le développement d'un logiciel scientifique impose donc une double contrainte d’adéquation scientifique et de flexibilité dans la durée. Il faut donc travailler au bon niveau d'abstraction et gérer avec le plus grand soin la dette technique. Sur ces deux points, la plupart des 'décideurs pressés' que j'ai croisé dans le monde scientifique académique (hors informatique) sont aussi notoirement incompétents que la plupart de leurs étudiants en thèse. Les objectifs des premiers sont de plus en plus d'avoir des sous et de bien se faire voir de leur hiérarchie, pas de faire avancer la recherche à travers de la mise à disposition de leurs outils/méthodes. Les objectifs des seconds sont de devenir le plus rapidement possible comme les premiers. Dans un cas comme dans l'autre, le premier objectif est la carrière personnelle.
Les très rares pros à la fois dans un domaine scientifique précis et en informatique, faute de possibilité de carrière et de reconnaissance dans le monde académique, préfèrent pour la plupart travailler dans le privé où les conditions sont bien plus avantageuses, lorsqu'ils ne sont pas jetés hors du monde académique parce qu'"on" ne veut pas comprendre pas de quoi et-ce qu'ils parlent et pourquoi est-ce que c'est important. Or, dans ce domaine: pas outils, pas de science (au sens de développement méthodologique), au mieux du service et de la sous-traitance qu'on nomme pudiquement "collaboration" et qui permet de réseauter pour assouvir les ambitions des égos.
Au final, c'est donc la science qui est en panne, faute d'outils fiables et de possibilité d'instaurer une dynamique de partage mutuellement gagnant-gagnant au sein de la communauté académique. YMMV, comme on dit, et heureusement ça a tendance à changer doucement, justement avec des mouvements comme Software Carpentry. Il y a du boulot.
A.
# krdc si tu utilises KDE ?
Posté par aurel (site web personnel, Mastodon) . En réponse au message Manager VNC. Évalué à 2.
Tout est dans le titre :)
# Codes de recherche orphelins
Posté par aurel (site web personnel, Mastodon) . En réponse au message Passer le flambeau. Évalué à 4.
Je suis dans la même situation que toi, et je crois que ce problème est très courant.
Le code informatique utilisé dans la recherche n'a souvent de financement que pour son développement initial, lequel se fait premièrement - souvent "seulement" - avec pour but d'en tirer une publication. La maintenance du code, la correction de bug, les modifications parfois nécessaires lorsque des dépendances changent, ne sont généralement pas considérées. Dès lors, les codes meurent assez rapidement. Cette tendance est si problématique qu'émergent des mouvements structurés pour la combattre, comme Software Carpentry, qui est justement en train de proposer un petit guide intéressant à l'usage des chercheurs.
En pratique, c'est à ceux qui ont besoin d'utiliser ce code de s'occuper d'en assurer la maintenance, et pas à toi, quand bien même c'est un peu "ton bébé". Surtout si tu as quitté le monde de la recherche, je te conseille de ne perd pas ton temps à essayer de t'en occuper: ça dédouanerait les utilisateurs de toutes responsabilités, ce qui contribuerait à pérenniser le système en place qui doit changer.
# Sauvegardons notre patrimoine
Posté par aurel (site web personnel, Mastodon) . En réponse au message Putain de continuum ! où est passée la spec d'IPOT. Évalué à 3.
Aucune idée d'où est passé la spec IPOT, mais ça me rappelle un trou noir dans lequel était tombé la-rache.com, avant de ressortir sur un dépôt github. Sans doute une idée à suivre pour IPOT, quand on le retrouvera, c'est à dire hier.
A.
# Dépêche !
Posté par aurel (site web personnel, Mastodon) . En réponse au journal Le logiciel libre au-delà de x86. Évalué à 10.
Non mais, tout ça est beaucoup, beaucoup trop intéressant pour ne pas être converti en dépêche !
Merci beaucoup !
[^] # Re: GRUB
Posté par aurel (site web personnel, Mastodon) . En réponse au message Chargeur d'amorçage simple et efficace ? genre GAG mais pour EFI ?. Évalué à 3.
Je crois avoir compris que ce qu'il souhaite, le monsieur, c'est un compte à rebours associé à une interface "graphique". GRUB ne permet pas de proposer un choix "graphique", si ?
[^] # Re: Il y'a plus simple justement
Posté par aurel (site web personnel, Mastodon) . En réponse au journal Promotion d'XMPP, message pour nos amis. Évalué à 2.
Pour étayer, ce post sur slahsdot.
[^] # Re: Il y'a plus simple justement
Posté par aurel (site web personnel, Mastodon) . En réponse au journal Promotion d'XMPP, message pour nos amis. Évalué à 7.
Telegram fait en effet du multi-device, mais pas lorsque le chiffrement de bout-en-bout est activé. Par défaut, il ne l'est pas. Pour qu'il le soit, il faut lancer un secret chat. Le client officiel Telegram Desktop n'implémente pas ces secret chats, au contraire d'autres clients - par exemple l'autre client officiel sur macOS Telegram Messenger (deux clients officiels? WTF?), lui, le propose. Le support est donc aléatoire. C'est pour cela que la réputation de "sécurité/confidentialité" de Telegram est passablement surfaite: beaucoup pensent que "par défaut", c'est chiffré entre les terminaux, alors que ça ne l'est que du terminal au serveur, que ce dernier voit tout passer, et que la plupart des utilisateurs n'ont même jamais vu l'option "secret chat"… bref…
Dans le cas du chiffrement de bout-en-bout implémenté dans ces secret chats, il n'y a pas de synchronisation possible entre les clients Telegram d'un même utilisateur, donc pas d'historique unifié entre les terminaux. En effet, les clés de chiffrements sur lesquelles se basent le chiffrement de bout-en-bout ne sont physiquement que sur les terminaux en cours de communication. Or, pour qu'une synchronisation a posteriori soit possible entre plusieurs terminaux d'un même utilisateur, il faudrait que ces clés soient partagées entre eux. Si les deux ne sont pas online en même temps, il faut donc également qu'elles soient stockées, ce qui est contradictoire avec leur caractère éphémères qu'impose la PFS. Comme elles ne sont stockées nulle part, elles sont impossible à synchroniser, et donc pas d'historique multi-device..
La solution apportée par Openwhisper Systems avec Signal est très élégante. L'implémentation proposée par WhatsApp est également un joli contournement du problème: le chat est toujours chiffré de bout-en-tout, et l'illusion du multi-device est donné par le fait que ton ordi avec WhatsApp Desktop ou équivalent se connecte à ton téléphone qui centralise chiffrement et historique. Du coup, tu as le beurre (le chiffrement de bout-en-bout) et l'argent du beurre (la synchronisation de l'historique, même si c'est une illusion puisqu'il ne quitte jamais ton téléphone).
Bref, Telegram c'est pas trop ça, en tout cas sur cet aspect là qui n'est sans doute pas qu'un détail pour beaucoup ici, par rapport à Signal ou surtout WhatsApp qui cumule cet avantage avec d'autres, comme le fait d'avoir une base d'utilisateur considérable.
[^] # Re: Pas encore à la hauteur
Posté par aurel (site web personnel, Mastodon) . En réponse au journal Promotion d'XMPP, message pour nos amis. Évalué à 7.
Je pense qu'on sera pas mal à partager ton point de vu.
Pour ma part, je complémente mon serveur XMPP auto-hébergé avec WhatsApp. Je trouve assez révélateur de constater que la plupart des personnes qui peuvent me contacter avec l'un ou avec l'autre échangent avec moi plus facilement via WhatsApp que via XMPP, quand bien même les clients sont installés sur leurs ordis/téléphones. N'utiliser qu'un seul service c'est s'en rendre dépendant, mais aussi minimiser la charge cognitive nécessaire à l'usage.
Du coup, en l'état mon serveur XMPP devient presque inutile, sauf comme fallback au besoin. Or, il existe des alternatives qui me sembleraient très bien jouer ce rôle d'appoint, sans nécessiter l'administration d'un serveur XMPP. Je pense par exemple à Tox, et en particulier à qTox (sur le desktop) et Antox (sur le mobile). Seul bémol: il n'y a pour l'instant aucune gestion du multi-device (donc aucun historique partagé ni gestion de la présence unifiée), ni PFS - et ça, c'est pour moi presque plus gênant et surtout incompréhensible. Heureusement, l'implémentation de l'un et de l'autre sont en route. Il faut juste être patient…
… et pendant ce temps, les autres solutions progressent aussi…
[^] # Re: Il y'a plus simple justement
Posté par aurel (site web personnel, Mastodon) . En réponse au journal Promotion d'XMPP, message pour nos amis. Évalué à 3.
Pour le coup, Telegram a accès au métadonnées (comme WhatsApp), mais le chiffrement de bout-en-bout est carrément planqué, pas disponible sur tous les clients, et surtout pas synchronisé entre eux. Dans la pratique, il n'est donc pas vraiment utilisable sauf à consentir à une gène à l'utilisation. WhatsApp me semble du coup être un meilleur compromis.
[^] # Re: Reflections: The ecosystem is moving
Posté par aurel (site web personnel, Mastodon) . En réponse au journal Promotion d'XMPP, message pour nos amis. Évalué à 2.
À noter que c'est justement dans le cadre d'un partenariat avec OpenWhisper Systems que WhatsApp a pu déployer son chiffrement de bout-en-bout. L'article de l'EFF à ce sujet est très intéressant à lire.
La gestion du multi-device est assez inattendue et je la trouve assez élégante: il est possible d'utiliser un client officiel sur son ordinateur (il existe des alternatives ici ou là), qui communiquent avec le téléphone sur lequel WhatsApp est installé, ce dernier restant en charge de toutes les opérations de chiffrement/déchiffrement. Bien sûr, il faut que le téléphone soit allumé et connecté, en contrepartie de quoi il est possible de faire du chiffrement de bout en bout tout en gardant un historique unifié et accessible depuis tous les terminaux.
Signal, d'OWS, fonctionne logiquement de la même façon. En attendant qu'il soit interopérable (on peut rêver, non?)…
[^] # Re: Il y'a plus simple justement
Posté par aurel (site web personnel, Mastodon) . En réponse au journal Promotion d'XMPP, message pour nos amis. Évalué à 2.
La possibilité d'interception ne serait-elle pas la même pour XMPP ? OK, OTR limite considérablement les risques, en tout cas si on vérifie les fingerprints sérieusement, sauf si on n'a qu'un terminal mobile et qu'il est MITMé dès la première connexion…
[^] # Re: Il y'a plus simple justement
Posté par aurel (site web personnel, Mastodon) . En réponse au journal Promotion d'XMPP, message pour nos amis. Évalué à 6.
De fait, la plupart des personnes utilisent sans poser de question justement parce que depuis leur propre perspective, ça "juste marche".
[^] # Re: prestashop
Posté par aurel (site web personnel, Mastodon) . En réponse au message Hébergement de site marchand. Évalué à 2.
Tu as aussi WooCommerce, qui est un plugin pour le classique Wordpress.
Suivant le positionnement de ton amie, il y a aussi le très connu alittlemarket, qui est une filiale d'Etsy. Il y a potentiellement beaucoup d'inconvénients à passer par un site dans ce genre, mais suivant les volumes de ventes qu'elle envisage de faire, ça peut être une option à considérer.
# Un parallèle...
Posté par aurel (site web personnel, Mastodon) . En réponse au journal Pourquoi une petite société a intérêt à contribuer et produire du libre... mais pas que. Évalué à 3.
… à faire avec cet article (en anglais).
[^] # Re: Mozilla's Tofino
Posté par aurel (site web personnel, Mastodon) . En réponse à la dépêche Sortie de Electron 1.0. Évalué à 3.
Autre application, le tout récent Whatsapp Desktop.
# Mozilla's Tofino
Posté par aurel (site web personnel, Mastodon) . En réponse à la dépêche Sortie de Electron 1.0. Évalué à 3.
C'est aussi Electron qui est utilisé par Mozilla pour son projet Tofino, travail exploratoire autour de l'interface utilisateur des navigateurs (source anglophone).
Le lien entre electron et chromium, et donc entre tofino est chromium, est perçue par certains comme un signe inquiétant concernant les principes et les bases techniques historiques de Mozilla.
# Suggestions: raccourcis clavier
Posté par aurel (site web personnel, Mastodon) . En réponse au journal JARR v1. Évalué à 3.
Vraiment très sympa, ce projet. Utilisateur de tt-rss, j'apprécie énormément les raccourcis claviers qui permettent par exemple de passer d'un article à l'autre sans avoir à toucher la souris. C'est le genre de chose qui enlarge tellement la productivity qu'il est difficile de s'en passer :)
[^] # Re: euh...
Posté par aurel (site web personnel, Mastodon) . En réponse au journal JARR v1. Évalué à 4.
Merci beaucoup d'avoir autorisé la création de comptes indépendants, je suis sûr que ça va permettre à beaucoup d'entre nous de tester :)
[^] # Re: PCimpact sont en grande forme
Posté par aurel (site web personnel, Mastodon) . En réponse au journal Baleine d'avril sur Nextinpact. Évalué à 3.
Ce qui est très rigolo concernant celui-là, c'est qu'un jour il sera vrai. À ce moment-là, on rigolera moins :-/
[^] # Re: Pull !
Posté par aurel (site web personnel, Mastodon) . En réponse au journal Quelles extensions pour votre Firefox?. Évalué à 2.
Est-ce que le RequestPolicy ne fait pas un peu doublon avec le mode "Dynamic Filtering" de uBlock Origin ?
[^] # Re: Ne pas jeter le bébé avec l'eau du bain
Posté par aurel (site web personnel, Mastodon) . En réponse au journal Partage: de ownCloud (décentralisé) à Syncthing (distribué). Évalué à 2.
Ces problèmes que tu décris m'évoquent Ricochet, mais ce dernier n'a rien à voir avec XMPP. C'est un système de messagerie instantanée anonyme et chiffré de bout en bout qui protège aussi bien le contenu que les métadonnées. Pour ce faire, il passe par TOR, et remplace l'identification par nom d'utilisateur / nom de serveur par le nom d'un service caché instancié en parallèle du client. La question du passage du NAT est donc déléguée à TOR, ainsi que le changement d'adresse IP également.