Ça a l'air très très précis sur les mesures (c'est plus un oscillo qu'un wattmètre), c'est une bête de course, mais c'est aux alentours des 300€ suivant les vendeurs !
La précision sur les puissances faibles est un bon argument si on s'intéresse aux consommation en veille. Par contre, la puissance maximale est de 1380W, ce qui exclut la plupart des appareils de chauffe.
Merci pour l'information, même si un tel bébé est un peu surdimensionné pour mes besoins :)
La puissance supportée est très bonne! À part ça, elle a l'air dans le même jeu de fonctionnalités que la Shelly Plug S, avec un firmware libre en prime :-)
À part la puissance supportée et une protection contre la surchauffe sur le petit modèle, ils ont les mêmes fonctionnalités (dont du MQTT, ou une API Rest, du wifi, un capteur thermique, un relai…).
L'article de NextImpact est, comme d'habitude, très bien.
J'utilise un dongle Flirc pour piloter un vieux PC avec une sortie sur un vidéoprojecteur. Le dongle est vu comme un périphérique USB-HID par le PC (comme une souris ou un clavier), donc pas de conf à faire sur la machine. Il est piloté par une télécommande universelle.
On peut configurer le dongle (associer événements infrarouges reçus et touches générées) depuis Linux.
Je ne sais pas si c'est lié mais j'ai pas mal de collègues avec des soucis de chauffe sur des MacBook pro. Ils migrent peut-être vers une architecture moins calorique. Sans être capable d'en juger, j'entendais jadis la qualité du hardware citée comme motif par des unixiens pour passer à Mac, mais ça revient de moins en moins souvent comme argument.
et peut être même l'incrémenter quelques lignes plus bas.
Et comment tu vas être sûr que tu ne risque pas te faire un overflow?
count c'est un "int", un "long" ? Ah, non pas de bol, il est lu d'un stream octet par octet, c'est un "byte".
Sur un langage moderne (j'imagine que Java a maintenant l'équivalent), on peut manipuler sans soucis le type d'une variable au type inféré:
autocounter=getNextValue();if(counter==numeric_limits<decltype(counter)>::max())throwoverflow_error("counter too big");++counter;
Intérêt: on devient insensible à une évolution de l'API de getNextValue(), par exemple si le type de retour passe de "int" à "long"…
Tu as raison, il me semble, dans tout ce que tu dis. Mais il me semble qu'on mélange deux choses:
D'un côté ton post souligne le problème de trouver (éventuellement) un modèle économique pour financer le logiciel libre.
Dans ce journal on parle de soumettre à l'impôt et aux cotisations sociales des activités qui sont déjà rémunératrices et qui n'ont aucun lien avec le partage ou le bénévolat. On parle essentiellement de sociétés qui utilisent le paravent du collaboratif pour échapper à l'impôt et aux cotisations sociales. Que fait Uber en collaboratif? Bon, ils doivent bien profiter de code libre pour leur plateforme, profiter du travail des chauffeurs pour s'enrichir, et après? Il me semble qu'une boîte comme ça est l'exact opposé d'un développeur libre peu ou pas financé. Je les rapprocherais même des boîtes que tu cites comme prenant des ressources collectives pour en faire du fric et ne jamais rien reverser en retour.
On parle de partage de code? L'impôt aussi, ça fait du partage: ça forme des programmeurs, ça fait de la recherche, ça ouvre de plus en plus les données, ça paie des gens qui font (aussi) du libre (sisi!)… Ça fait les routes pour les chauffeurs d'Uber, ça fait la voirie pour évacuer les déchets qu'on laisse après son passage dans un logement BnB… Est-ce collaboratif de ne pas payer l'impôt?
Quand au journal, finir sur le manque de financement des développeurs du libre pour essayer de nous tirer une larme, ça sent la grossière manipulation. Pour rappel, Travis Cordell Kalanick "vaut" 6.2 milliards de dollars d'après Wikipédia, et je ne vois pas en quoi il a donné quoi que ce soit à la collectivité.
Merci, non seulement pour les rencontres et l'annonce alléchante du programme mais aussi pour le travail d'exhumation des anciennes rencontres et autres sources.
Ça a l'air très très bien ces meetup ! Du coup, alléché mais ne pouvant faire le déplacement régulièrement, je me demandais si on pouvait trouver une version en ligne de ces rencontres, que ce soit une vidéo, ou au pire les slides (le quizz, le quizz!!). En grattant un peu:
Alors c'est lui aussi, les numéros de séquence de TCP et le 3 way handshake! C'est beau de simplicité.
On a des tout grands barbus qui disparaissent (aussi Postel et Ritchie, j'espère que Cerf, Thomson et Kernigham prennent soin de sa santé). Ils ont contribué à monter les bases de l'informatique d'aujourd'hui sans faire fortune avec, sans faire trop de bruit.
À côté de ça, demandez (non, pas autour de vous, c'est pas représentatif) qui sont les grands informaticiens et on vous balancera le nom de milliardaires…
Pour ceux qui (comme moi) se posent la question "Où en est le sympathique btrfs face au sympathique Zfs" (on est pas vendredi), on a des pistes de réponse rapides dans une Comparaison wikipedia de systèmes de fichiers
TL;DR: ce qui me semble le plus limitant est l'absence de chiffrement de btrfs, sinon, ça a l'air très proche dans l'avancement.
Ceci dit, la comparaison est vraiment générale et les listes wikipedia sont parfois sujettes à erreurs. Voici donc d'autres sources:
On a un test de perfs récents dans un rapport de projet de fin d'étude. Btrfs a l'air d'assurer de plus gros débits que Zfs, mais la question de la stabilité est posée.
Il y a les slides d'un talk à la Linuxcon 2014 avec pas mal de détail, notamment sur la licence mais l'auteur est peut-être partial ;)
Si vous avez d'autres bonnes sources récentes, je suis preneur :)
J'ai mal utilisé le terme chiffrement: je pensais à une injection de clé, avec en plus un "key streching" (désolé, pas d'idée de traduction) histoire d'augmenter l'entropie et de ralentir le hachage (pas besoin de vitesse en utilisation normale dans ce cas) pour limiter le bruteforce, le tout itéré avec une bonne fonction de hachage (Keccak?). C'est un peu ce que tu décris, sauf qu'il y a peu d'itérations (10 me semble bien faible mais c'est bien leur défaut, tu as raison!) et que, par défaut, ils se contentent d'un hash MD5 (voir leur code) alors qu'ils utilisent crypto-js qui supporte du sha3 (donc du Kekkac).
Dommage, je trouvais l'idée sympa. Enfin, ça reste toujours mieux que du mot de passe identique partout…
Sinon, qq'un a une idée de comment le navigateur assure qu'un "processus" (pas au sens système) javascript ne peut jamais accéder à la mémoire d'un autre "processus"? C'est threadé et laissé à l'OS? Je pensais au mot de passe maître qui réside en mémoire et ça ne m'inspire pas confiance (à tort?).
| C'est une bonne idée à la condition que l'information sur le fait que tu utilises supergenpass reste secrète.
Non, c'est pas juste un hachage du nom du site : c'est un chiffrement du nom du site avec une clé (commune à tous les sites) si j'ai bien compris les explications. Tant qu'ils n'ont pas la clé, l'algo ne suffit pas.
Pour l'interaction Web/Keepass, il existe Keefox, un module firefox pour s'interfacer avec Keepass. Je n'ai jamais essayé.
PS: Je me réponds parce que je ne peux plus modifier le post: j'ai un joli logo de Gandalf qui m'interdit de passer en me prenant pour un Balrog alors que le bouton "Modifier" est présent. On a une limite du nombre de modifs / unité de temps sous LinuxFr?
Ma solution: un git privé qui partage qq fichiers dont un fichier keepassx protégé par une masterkey.
Inconvénients:
- Bien sûr, les mécanismes de merge de git sont sans intérêt sur un fichier chiffré: penser à bien synchroniser avant et après chaque modif.
- Git se fout des droits (lecture pour tout le monde): bien penser à protéger les répertoires en amont en cas d'attaque locale
- Il me faut un serveur accessible 24/7
Intérêts:
- J'utilise déjà pas mal Git pour de la synchro/sauvegarde, du coup pas un outil de plus à maintenir
- J'ai relativement confiance en Git pour la sécurité. Au pire, si mon Git est compromis, il me reste la masterkey.
- Même si le diff n'a aucun sens sur ma base de mots de passes, je bénéficie quand même de la possibilité de remonter une ancienne version de mes mots de passe (y compris si mon dépot local si l'origin n'est pas accessible).
- Je ne pose pas mes données sensibles sur la machine de quelqu'un d'autre.
ps: Comme notifié plus haut, keepass, c'est pas un champion de l'intégration automatique dans toutes les applis. Mais en pratique, ça ne me gêne pas trop (surtout des pass web et des accès via SSH avec des authorized key (pas besoin du pass)).
C'est la reprise de ma solution 1. Trop manuel pour moi, il faut automatiser, que diable! :)
Et l'automatisation pose justement un problème, vu que je n'arrive pas à trouver de critère pour permettre à i3 de faire la différence entre les fenêtres en question.
Merci beaucoup d'avoir testé tout ça (ça me permet de confirmer que le bug existe toujours, contrairement aux rapports de bug fermés), et content du rappel de i3 :)
ps: Je vois néanmoins une solution d'automatisation à base de binding de touche et de xdotool mais on est pas assez vendredi pour proposer une horreur comme ça :)
Mes p'tits gars n'auront plus d'excuses pour ne pas accentuer correctement leurs majuscules (Bordel, elle s'appelle "CAPS-lock", pas "SHIFT-lock", la touche de verrouillage!).
[^] # Re: Sonoff
Posté par Trollgouin . En réponse au message Prise wattmètre connectée accessible via Linux. Évalué à 1.
Prix 2022:
Par contre, j'ai pas vu dans le descriptif d'indication d'un retour sur la puissance consommée (mais j'imagine que tu as testé).
Merci!
[^] # Re: Tasmota
Posté par Trollgouin . En réponse au message Prise wattmètre connectée accessible via Linux. Évalué à 1.
Et ils ont des relais sympas aussi. Merci de l'info!
[^] # Re: PowerSpy2
Posté par Trollgouin . En réponse au message Prise wattmètre connectée accessible via Linux. Évalué à 1.
Ça a l'air très très précis sur les mesures (c'est plus un oscillo qu'un wattmètre), c'est une bête de course, mais c'est aux alentours des 300€ suivant les vendeurs !
La précision sur les puissances faibles est un bon argument si on s'intéresse aux consommation en veille. Par contre, la puissance maximale est de 1380W, ce qui exclut la plupart des appareils de chauffe.
Merci pour l'information, même si un tel bébé est un peu surdimensionné pour mes besoins :)
[^] # Re: Tasmota
Posté par Trollgouin . En réponse au message Prise wattmètre connectée accessible via Linux. Évalué à 3.
En 2022, elle est là, à 18€:
La puissance supportée est très bonne! À part ça, elle a l'air dans le même jeu de fonctionnalités que la Shelly Plug S, avec un firmware libre en prime :-)
Merci!
[^] # Re: Un article de NextInpact sur le sujet ...
Posté par Trollgouin . En réponse au message Prise wattmètre connectée accessible via Linux. Évalué à 3.
Alors, en version prises, on trouve en 2022 deux modèles:
À part la puissance supportée et une protection contre la surchauffe sur le petit modèle, ils ont les mêmes fonctionnalités (dont du MQTT, ou une API Rest, du wifi, un capteur thermique, un relai…).
L'article de NextImpact est, comme d'habitude, très bien.
Et encore merci :)
[^] # Re: MQTT
Posté par Trollgouin . En réponse au message Prise wattmètre connectée accessible via Linux. Évalué à 2.
Je plussoie l'intérêt de MQTT là dessus. C'est tellement simple à utiliser, et pas de polling!
# Merci!
Posté par Trollgouin . En réponse au message Prise wattmètre connectée accessible via Linux. Évalué à 1.
Merci pour toutes vos réponses! C'est tout à fait les pistes dont j'avais besoin! 😘
# Flirc
Posté par Trollgouin . En réponse au message [Décodeur TV Raspberry pi] : Recherche émetteur/récepteur infrarouge. Évalué à 2.
J'utilise un dongle Flirc pour piloter un vieux PC avec une sortie sur un vidéoprojecteur. Le dongle est vu comme un périphérique USB-HID par le PC (comme une souris ou un clavier), donc pas de conf à faire sur la machine. Il est piloté par une télécommande universelle.
On peut configurer le dongle (associer événements infrarouges reçus et touches générées) depuis Linux.
[^] # Re: Pas de soucis !
Posté par Trollgouin . En réponse au journal 2020 année de Linux sur le desktop .... Évalué à 3.
Je ne sais pas si c'est lié mais j'ai pas mal de collègues avec des soucis de chauffe sur des MacBook pro. Ils migrent peut-être vers une architecture moins calorique. Sans être capable d'en juger, j'entendais jadis la qualité du hardware citée comme motif par des unixiens pour passer à Mac, mais ça revient de moins en moins souvent comme argument.
[^] # Re: Inférence de types
Posté par Trollgouin . En réponse à la dépêche Sortie de JDK 10. Évalué à 7.
Sur un langage moderne (j'imagine que Java a maintenant l'équivalent), on peut manipuler sans soucis le type d'une variable au type inféré:
Intérêt: on devient insensible à une évolution de l'API de getNextValue(), par exemple si le type de retour passe de "int" à "long"…
[^] # Re: Quid des hackers ? Ben voila "quid des hackers"
Posté par Trollgouin . En réponse au journal Le Bon Coin, Airbnb, Uber : Les prochaines poules aux œufs d'or. Évalué à 1.
Tu as raison, il me semble, dans tout ce que tu dis. Mais il me semble qu'on mélange deux choses:
D'un côté ton post souligne le problème de trouver (éventuellement) un modèle économique pour financer le logiciel libre.
Dans ce journal on parle de soumettre à l'impôt et aux cotisations sociales des activités qui sont déjà rémunératrices et qui n'ont aucun lien avec le partage ou le bénévolat. On parle essentiellement de sociétés qui utilisent le paravent du collaboratif pour échapper à l'impôt et aux cotisations sociales. Que fait Uber en collaboratif? Bon, ils doivent bien profiter de code libre pour leur plateforme, profiter du travail des chauffeurs pour s'enrichir, et après? Il me semble qu'une boîte comme ça est l'exact opposé d'un développeur libre peu ou pas financé. Je les rapprocherais même des boîtes que tu cites comme prenant des ressources collectives pour en faire du fric et ne jamais rien reverser en retour.
On parle de partage de code? L'impôt aussi, ça fait du partage: ça forme des programmeurs, ça fait de la recherche, ça ouvre de plus en plus les données, ça paie des gens qui font (aussi) du libre (sisi!)… Ça fait les routes pour les chauffeurs d'Uber, ça fait la voirie pour évacuer les déchets qu'on laisse après son passage dans un logement BnB… Est-ce collaboratif de ne pas payer l'impôt?
Quand au journal, finir sur le manque de financement des développeurs du libre pour essayer de nous tirer une larme, ça sent la grossière manipulation. Pour rappel, Travis Cordell Kalanick "vaut" 6.2 milliards de dollars d'après Wikipédia, et je ne vois pas en quoi il a donné quoi que ce soit à la collectivité.
# Merci
Posté par Trollgouin . En réponse à la dépêche Douzième rencontre parisienne C++ mercredi 27 avril 2016. Évalué à 2.
Merci, non seulement pour les rencontres et l'annonce alléchante du programme mais aussi pour le travail d'exhumation des anciennes rencontres et autres sources.
# Alléchant...
Posté par Trollgouin . En réponse à la dépêche Onzième rencontre C++ francophone jeudi 31 mars 2016 à Paris. Évalué à 2.
Ça a l'air très très bien ces meetup ! Du coup, alléché mais ne pouvant faire le déplacement régulièrement, je me demandais si on pouvait trouver une version en ligne de ces rencontres, que ce soit une vidéo, ou au pire les slides (le quizz, le quizz!!). En grattant un peu:
Les slides.
Les vidéos. Attention, le lien sur le site des rencontres (et non pas le site de rencontres) est faux: il y a un tiret en trop dans l'adresse.
[^] # Re: Deux témoignages techniques
Posté par Trollgouin . En réponse au journal Ray Tomlinson est décédé. Évalué à 4.
Alors c'est lui aussi, les numéros de séquence de TCP et le 3 way handshake! C'est beau de simplicité.
On a des tout grands barbus qui disparaissent (aussi Postel et Ritchie, j'espère que Cerf, Thomson et Kernigham prennent soin de sa santé). Ils ont contribué à monter les bases de l'informatique d'aujourd'hui sans faire fortune avec, sans faire trop de bruit.
À côté de ça, demandez (non, pas autour de vous, c'est pas représentatif) qui sont les grands informaticiens et on vous balancera le nom de milliardaires…
… :(
# Zfs vs BTRFS
Posté par Trollgouin . En réponse à la dépêche ZFS, Canonical et GPL. Évalué à 5.
Pour ceux qui (comme moi) se posent la question "Où en est le sympathique btrfs face au sympathique Zfs" (on est pas vendredi), on a des pistes de réponse rapides dans une Comparaison wikipedia de systèmes de fichiers
TL;DR: ce qui me semble le plus limitant est l'absence de chiffrement de btrfs, sinon, ça a l'air très proche dans l'avancement.
Ceci dit, la comparaison est vraiment générale et les listes wikipedia sont parfois sujettes à erreurs. Voici donc d'autres sources:
On a un test de perfs récents dans un rapport de projet de fin d'étude. Btrfs a l'air d'assurer de plus gros débits que Zfs, mais la question de la stabilité est posée.
Il y a les slides d'un talk à la Linuxcon 2014 avec pas mal de détail, notamment sur la licence mais l'auteur est peut-être partial ;)
Si vous avez d'autres bonnes sources récentes, je suis preneur :)
[^] # Re: Base de la position de Canonical
Posté par Trollgouin . En réponse à la dépêche ZFS, Canonical et GPL. Évalué à 7.
Il est même utilisé en production dans quelques coins, notamment sur certains téléphones.
D'un autre côté, une vieux système de fichier, ça a un côté rassurant, surtout que Sun s'est toujours bien débrouillé pour les IO.
[^] # Re: SuperGenPass
Posté par Trollgouin . En réponse au journal Où mettre son archive de mots de passe ?. Évalué à 1.
Arg. J'aurais du relire tout le thread avant de répondre :)
On a les mêmes inquiétudes…
[^] # Re: SuperGenPass
Posté par Trollgouin . En réponse au journal Où mettre son archive de mots de passe ?. Évalué à 3.
Merci pour les infos:
J'ai mal utilisé le terme chiffrement: je pensais à une injection de clé, avec en plus un "key streching" (désolé, pas d'idée de traduction) histoire d'augmenter l'entropie et de ralentir le hachage (pas besoin de vitesse en utilisation normale dans ce cas) pour limiter le bruteforce, le tout itéré avec une bonne fonction de hachage (Keccak?). C'est un peu ce que tu décris, sauf qu'il y a peu d'itérations (10 me semble bien faible mais c'est bien leur défaut, tu as raison!) et que, par défaut, ils se contentent d'un hash MD5 (voir leur code) alors qu'ils utilisent crypto-js qui supporte du sha3 (donc du Kekkac).
Dommage, je trouvais l'idée sympa. Enfin, ça reste toujours mieux que du mot de passe identique partout…
Sinon, qq'un a une idée de comment le navigateur assure qu'un "processus" (pas au sens système) javascript ne peut jamais accéder à la mémoire d'un autre "processus"? C'est threadé et laissé à l'OS? Je pensais au mot de passe maître qui réside en mémoire et ça ne m'inspire pas confiance (à tort?).
[^] # Re: SuperGenPass
Posté par Trollgouin . En réponse au journal Où mettre son archive de mots de passe ?. Évalué à 1.
| C'est une bonne idée à la condition que l'information sur le fait que tu utilises supergenpass reste secrète.
Non, c'est pas juste un hachage du nom du site : c'est un chiffrement du nom du site avec une clé (commune à tous les sites) si j'ai bien compris les explications. Tant qu'ils n'ont pas la clé, l'algo ne suffit pas.
[^] # Re: Git + keepassx
Posté par Trollgouin . En réponse au journal Où mettre son archive de mots de passe ?. Évalué à 1.
Pour l'interaction Web/Keepass, il existe Keefox, un module firefox pour s'interfacer avec Keepass. Je n'ai jamais essayé.
PS: Je me réponds parce que je ne peux plus modifier le post: j'ai un joli logo de Gandalf qui m'interdit de passer en me prenant pour un Balrog alors que le bouton "Modifier" est présent. On a une limite du nombre de modifs / unité de temps sous LinuxFr?
# Git + keepassx
Posté par Trollgouin . En réponse au journal Où mettre son archive de mots de passe ?. Évalué à 4. Dernière modification le 26 janvier 2016 à 09:32.
Ma solution: un git privé qui partage qq fichiers dont un fichier keepassx protégé par une masterkey.
Inconvénients:
- Bien sûr, les mécanismes de merge de git sont sans intérêt sur un fichier chiffré: penser à bien synchroniser avant et après chaque modif.
- Git se fout des droits (lecture pour tout le monde): bien penser à protéger les répertoires en amont en cas d'attaque locale
- Il me faut un serveur accessible 24/7
Intérêts:
- J'utilise déjà pas mal Git pour de la synchro/sauvegarde, du coup pas un outil de plus à maintenir
- J'ai relativement confiance en Git pour la sécurité. Au pire, si mon Git est compromis, il me reste la masterkey.
- Même si le diff n'a aucun sens sur ma base de mots de passes, je bénéficie quand même de la possibilité de remonter une ancienne version de mes mots de passe (y compris si mon dépot local si l'origin n'est pas accessible).
- Je ne pose pas mes données sensibles sur la machine de quelqu'un d'autre.
ps: Comme notifié plus haut, keepass, c'est pas un champion de l'intégration automatique dans toutes les applis. Mais en pratique, ça ne me gêne pas trop (surtout des pass web et des accès via SSH avec des authorized key (pas besoin du pass)).
[^] # Re: faudra que j'essaie
Posté par Trollgouin . En réponse au message La console de présentation de libreoffice et I3 (ou awsome, ou e17...). Évalué à 1.
C'est la reprise de ma solution 1. Trop manuel pour moi, il faut automatiser, que diable! :)
Et l'automatisation pose justement un problème, vu que je n'arrive pas à trouver de critère pour permettre à i3 de faire la différence entre les fenêtres en question.
Merci beaucoup d'avoir testé tout ça (ça me permet de confirmer que le bug existe toujours, contrairement aux rapports de bug fermés), et content du rappel de i3 :)
ps: Je vois néanmoins une solution d'automatisation à base de binding de touche et de xdotool mais on est pas assez vendredi pour proposer une horreur comme ça :)
[^] # Re: gestionnaire de fenêtres
Posté par Trollgouin . En réponse au message La console de présentation de libreoffice et I3 (ou awsome, ou e17...). Évalué à 3.
Modifié, merci :)
Sinon, i3, c'est un gestionnaire "rangeant" tes fenêtres, c'est déjà pas si mal :P
[^] # Re: faudra que j'essaie
Posté par Trollgouin . En réponse au message La console de présentation de libreoffice et I3 (ou awsome, ou e17...). Évalué à 1.
Merci :)
# Majuscules accentuées
Posté par Trollgouin . En réponse à la dépêche Sortie de WinCompose 0.7.5. Évalué à 1.
Super idée! À toi, mille mercis!
Mes p'tits gars n'auront plus d'excuses pour ne pas accentuer correctement leurs majuscules (Bordel, elle s'appelle "CAPS-lock", pas "SHIFT-lock", la touche de verrouillage!).