La version TF1/France2(/Max Havelaar ?) est une vision caritative : tu payes ton petit noir plus cher pour que le petit noir qui le cueille ait un peu plus de sous.
Pour d'autres, c'est la mise en place d'une économie alternative au capitalisme prédateur qui permette à chacun d'y trouver son compte à chaque maillon de la chaîne, en toute transparence, plutôt que de tirer la couverture et d'user de rapports de force pour écraser son prochain.
Il y a donc une vision caritative réductrice et une vision militante politique idéaliste.
D'un côté on dit au consommateur "tiens, achète-ça, c'est bien, tu auras la conscience tranquille, notre marque est la plus gentille et en plus c'est bon", de l'autre on lui dit "voilà ce qu'on a essayé de faire, c'est pas encore parfait, voilà où on en est, voilà l'impact que ça a sur les communautés, on est en train d'essayer de faire mieux, et on réfléchit à un commerce équitable nord-nord".
Il est clair que si on considère une pub pour un produit labellisé Max Havelaar vendu à Carrefour, le projet politique est difficile à retrouver. Il est absent de la communication. En revanche, on fait du volume et certains diront que les idéalistes qui font du travail de proximité et créent des filières qui approvisionnent le petit magasin du centre ville ont un impact beaucoup plus faible. Du volume, mais à quel prix ?
Oui, les supermarchés enfreignent régulièrement le droit, au même titre que beaucoup d'employeurs (et d'employés) et parfois même que la petite boutique du coin, au sein de laquelle la présence syndicale doit être en plus inexistante, rien n'est parfait. D'ailleurs pour éviter d'avoir à l'enfreindre, ils l'écrivent (ANI). En tout cas le fait est qu'ils ne cherchent qu'à maximiser un profit, en tirant les coûts vers le bas (pression côté producteur) et en vendant cher les produits bio/équitables (niche à destination des gens qui sont prêts à mettre plus cher, autant en profiter).
Ce commentaire ne vise pas à diaboliser le Super U de Parthenay.
Peut-être prendre les choses une par une. En attendant la migration Squeeze -> Wheezy (à faire dans un environnement stable et avec du temps devant soi), je m'amuserais pas à introduire des paquets Wheezy pour résoudre une problème, sauf à être certain de ce que je fais.
Dans le log, il doit y avoir une trace des opérations précédentes, aussi.
D'accord sur le fond mais je crois que ce que veut dire Ken Thompson, c'est qu'il est capable d'intégrer du code malveillant (backdoor ?) dans le code qu'il te livre, avec suffisamment de finesse pour que tu ne le voies pas à la relecture avant de le compiler toi-même.
Ce qui peut se comprendre. S'il suffit d'un débordement de buffer bien placé pour passer root sur une machine, il est alors facile de proposer un système avec une faille volontaire qui passe inaperçue.
C'est plus difficile de proposer un linux personnalisé avec une faille volontaire, puisque seuls les patches seraient à contrôler en priorité. Alors que des milliers ou millions de lignes de code Windows sans versionnement, c'est sans doute compliqué à auditer.
Les bugtrackers sont souvent intéressant à lire. On comprend (en partie) pourquoi l'intégration d'un logiciel n'est pas si évidente, même si l'auteur fournit un .deb.
Apparemment, en debian stable c'est corrigé mais en testing ? Pourquoi est-ce que le fix n'est pas présent sur la branche testing ?
Parce qu'on attend la 3.8 de unstable qui arrive pas ?
Parce que quand on est en testing on doit aussi avoir une référence à stable-sec dans son sources.list de sorte que le paquet corrigé a priorité ? C'est quoi la ligne qui correspond ? Moi, j'ai ça, et je vois pas de 3.2.41-2+deb7u2 dans aptitude.
deb http://mirrors.ircam.fr/pub/debian/ testing main non-free
deb http://security.debian.org/ testing/updates main non-free
deb http://ftp.debian.org/debian experimental main
Merci pour cette initiative. Ça fait longtemps que je voulais écrire une dépêche pour présenter le projet OEM. L'occasion a fait le larron et ça m'a un peu boosté pour publier, sinon je serais encore en train d'attendre des résultats sympas à monter ou la nouvelle fonctionnalité qui tue.
La dépêche a donné un peu de visibilité francophone au projet et a suscité au moins une vocation : un DLFPien bâtisseur et enthousiaste qui a rejoint le projet pour instrumenter sa future maison.
j’imagine que pour Chromium c’est sans doute plus facile vu qu’ils font la barre de recherche à leur sauce, alors que celle de Firefox bah c’est celle de GTK.
La phrase laisse entendre que c'est la barre de recherche qui est Gtk, mais l'auteur a peut-être voulu parler de la barre de défilement.
Je n'ai jamais été attiré par les simulateurs de vol, que j'assimile soit à des "jeux d'avion", soit à des trucs compliqués super réalistes.
Mais j'ai toujours eu dans l'idée quand j'étais gamin qu'un jour on aurait une représentation du monde assez précise pour faire des jeux d'avion en monde réel et ça, ça change tout. Avec ces captures d'écran, j'ai l'impression qu'on en prend le chemin, ça fait envie.
Quand on navigue sur une carte sur internet, on s'en approche, mais c'est moins sympa.
J'ai toujours utilisé aptitude (le semi-graphique, j'adore, j'y peut rien…) mixé avec apt-get (parce qu'au début je suivait les conseils des forums quand j'avais un problème précis) et ma première installation (en tout cas, que j'aie réellement utilisée) de Debian était une Lenny.
Je n'ai jamais eu de soucis de ce côté là.
Oui, j'ai recherché une source exacte, pas trouvé. Apparemment c'est plus vrai depuis longtemps, tant mieux.
Je ne comprend pas ce que tu veux dire au sujet du partage de gestion des dépendances… aptitude est, comme apt-get et synaptic, un front-end à dpkg.
Il me semblait que l'état "installé automatiquement" était stocké dans une base de donnée propre à aptitude, pas à dpkg. Et donc bazar si on mélange les deux.
Mais on peut pas proposer ça a un débutant si on veut le garder.
J'ai commencé avec Ubuntu/Synaptic et je trouvais ça pas mal. Autant je suis fan d'aptitude en ncurse, autant je persiste à dire que c'est précisément le genre d'interface qui fait fuir un débutant, que ça soit l'apparence, les raccourcis, etc. Synaptic a aussi une interface de gestion des dépôts qui évite de devoir éditer sources.list à la main. Et je me vois pas proposer un linux à un débutant s'il n'y a pas un truc comme ça. Et l'applet de mise à jour automatique (update-notifier).
Je préfère moi aussi l'interface ncurse d'aptitude à une ligne de commande apt-get ou aptitude. L'avantage de la ligne de commande est qu'elle se copie facilement sur un forum.
Là encore, je peux me planter, mais il me semble que Debian n'a jamais réellement ciblé les utilisateurs débutants
Je sais pas, mais l'installeur par défaut me semble pas mal et permet à un débutant d'installer et d'avoir un système joli qui tourne. Sous réserve de comprendre qqchose à Gnome Shell (moi j'y comprends rien), ou a un autre bureau de son choix, il peut se débrouiller. Donc autant avoir un système complètement "accessible".
Si je dois installer un linux chez un proche, j'hésite entre stable/Xfce et testing/Xfce, selon son expertise, son besoin de bleeding-edge, et ma proximité.
C'est une bonne nouvelle (enfin c'est peut-être nouveau que pour moi…). Ça veut dire qu'on peut installer une Debian avec Synaptic chez un débutant et intervenir dessus en utilisant aptitude sans mettre le bazar.
en tout cas je n'ai pas l'impression que mixer apt-get […] et aptitude (selon mon humeur j'utilise l'un ou l'autre) affecte mon système.
Je n'ai jamais testé mais j'ai lu précisément le contraire ! Attention. (Ça doit pas être trop dur à tester…)
tu as oublié quelques défauts (au mois présents en mode semi-graphique): il est lent, et il est aussi peu voire pas adapté a multi-arch
Je ne l'ai jamais trouvé lent. Jusqu'à ce que je l'utilise sur un Raspberry Pi. Sur mon PC le tri se fait rapidement et j'ai très vite la main après le lancement.
Multi-arch j'utilise pas, mais ça doit faire partie des options manquantes au même titre que le tri par dépôt. Ça devrait pas être si compliqué à rajouter.
Je comprends qu'il ne soit pas recommandé : l'approche est peut-être de préconiser Synaptic et de laisser les plus expérimentés passer à apt-get en ligne de commande, qui partage la gestion de dépendances auto de Synaptic.
Je n'utilise aptitude presque qu'en mode ncurse et je le préfère à Synaptic, justement. Et puis ça a le mérite de me faire la même interface sur le PC que sur le serveur et le Rapsberry Pi. Mais on peut pas proposer ça a un débutant si on veut le garder. Pas tout de suite.
Je crois que ça a été le cas (pour Wheezy, je crois) du fait de limitation d'apt-get sur la gestion des dépendances en particulier mais que ça ne l'est plus car ces limitations n'existent plus. Ce serit donc à nouveau apt-get qui serait recommandé.
J'utilise aptitude aussi et maintenant que j'ai commencé je le garde pour conserver l'état "installé automatiquement" de mes paquets, même si je change de version de distro. En tout cas tant qu'aptitude est maintenu.
C'est quand même pratique, aptitude, puisqu'à la fois rapide et puissant. Il manque quelques filtres automatiques (tri par dépôt d'origine, par exemple), mais ça reste bien.
Ça ne résoudrait le problème que pour les villes avec une mairie (bon, je crois qu'en France ça ne pose pas de problème, mais en Belgique, beaucoup de village font partie d'une commune située dans la ville la plus proche), mais pas pour les lieux-dit ou tout autre lieu qui n'est pas forcément sur une route (tous les points d'intérêt en fait).
Effectivement, je n'y avais pas pensé. Et ça saute aux yeux si on zoome et qu'on constate que le point se trouve juste à côté d'une route. La projection est effectivement une bonne solution évidente et générique.
Pour les villes, ça marchera bien si les noeuds "nom de ville" sont placés à un endroit pertinent sur la carte.
Ça pourrait à la limite coincer si les règles de placement des noms de ville selon OSM (à Bordeaux, c'est à côté de la place Gambetta, je sais pas pourquoi, à Toulouse c'est au Capitole, l'hôtel de ville) diffèrent de celles que l'on aimerait pour un calcul d'itinéraire (mairie pour coller aux panneaux routiers ?), mais c'est déjà plus de l'ordre du détail.
OK je comprends. Ton contournement doit fonctionner, mais ça fait partie de ces petits détails qui rendent le sites de calcul d'itinéraire depuis OSM moins agréables à utiliser. J'ai beau vouloir faire de la résistance, il faut reconnaître que Google Maps c'est super fluide.
Là c'est embêtant parce que je crois que la solution nécessite intervention sur les cartes OSM elles-mêmes, pas seulement au niveau du serveur de calcul d'itinéraire :
soit définir un nouveau type de noeud spécialement dédié à ça
soit forcer les noeuds de nom de ville à être à un endroit exploitable
Cet endroit pourrait être la mairie, qui est en général desservie par le réseau routier et de transports en commun. C'est peut-être d'ailleurs ce point qui est utilisé pour déterminer la distance à une ville (panneaux routiers).
J'ai bien conscience que la bonne réponse à la question "combien de temps de Bordeaux à Limoges ?" est "Ben ça dépend, tu pars de quel endroit à Bordeaux ?" mais c'est quand même un besoin courant. Et ça n'empêche pas d'affiner après en déplaçant les indicateurs de départ et d'arrivée.
La dernière fois que j'ai fait ça, pour une mise à jour mineure, j'ai eu un petit problème.
Le script de mise à jour est chargé d'arrêter le vieux cluster, mais chez moi, il n'y parvenait pas. Je pouvais l'arrêter moi-même avec l'option --force, mais il faut que le script le fasse lui-même parce qu'il a des choses à demander au cluster avant. En gros.
J'ai donc modifié /usr/bin/pg_upgradecluster pour remplacer le timeout par un force:
- my @argv = ('pg_ctlcluster', $version, $cluster, 'stop', '--', '-t', '5');
+ my @argv = ('pg_ctlcluster', $version, $cluster, 'stop', '--force');
et ça a fonctionné.
Le script de mise à jour a été modifié pour pouvoir fonctionner avec un cluster arrêté (il le redémarre avec une connexion restreinte). Ça permet de l'arrêter à la main avec --force avant, dans le cas où le script n'y arrive pas avec l'option timeout.
Je comprends. C'est clairement pas le priorité des développeurs que de réfléchir à ça (cf. les commentaires en bas de cette page). Je signale ça à Trystan. Merci.
Est-il possible de se passer des transmetteurs radio pour utiliser du RJ-45 ? (je suis pas trop fan des "choses" qui émettent des ondes directement dans la maisons)
Je ne suis pas fan non plus. Quand on peut passer un fil, je préfère. Ce n'est pas l'optique choisie par le projet. Sans doute pour pouvoir s'adapter à l'existant. Selon la grandeur que tu cherches à mesurer, tu peux reproduire un peu la même chose avec un arduino et un shield ethernet.
Je crois que la prochaine version du TX prévoit un emplacement vide pour un connecteur Xbee optionnel (radio toujours) mais rien pour de l'ethernet.
Dans une maison neuve, tu peux passer du RJ45 partout donc c'est intéressant pour toi de regarder vers là, en effet. En bon geek, j'en mettrais un peu plus que le minimum (par exemple des prises à deux ports dans chaque pièce) histoire d'être tranquille.
Est-il possible de rajouter des sondes de température / luminosité / humidité ? (Idéalement un groupe par pièce)
Ce genre de chose est possible, oui. Dans la config de base, non, c'est un seul port pour ça par emonTX. Ca vaudrait le coup de prendre un arduino + shield ethernet et faire un truc à plusieurs ports (temp, lum, humidité). C'est pas forcément la mort en s'inspirant des docs du site, vraiment. Jette un coup d'oeil à la page Building Blocks qui détaille les morceaux. Et n'hésite pas à intervenir sur le forum si tu es intéressé, tu ne serais pas le seul.
Comme la construction doit déjà pas mal te mobiliser, je doute que tu aies des masses de temps pour développer ça, mais pense aux ports éthernet partout, tu auras toujours le temps de voir. Côté EDF, je ne sais pas s'il y a le choix pour le compteur et si ça vaut le coup de se renseigner avant pour en choisir un avec une sortie plus pratique à récupérer.
Je suppose qu'il est possible de remplacer emoncms par autre chose. C'est plus une contrainte perso puisque j'ai bannis depuis un bon moment php/mysql de mes serveurs pour plateforme Ruby/Rails/Postgresql/Mongodb
Oui, ce n'est pas grand chose à modifier. Comme je le dis en dépêche c'est assez modulaire.
Tu penses à une implémentation perso de zéro ? Je n'ai pas essayé les alternatives citées dans la dépêche, mais regarde du côté de ThingSpeak, par exemple, et dis-nous ce que ça donne.
J'avais cherché ton nom sur DLFP avant de poster. Bienvenu à toi. Je sais pas si tu as fait attention, mais je mentionne vos contributions dans la dépêche, dans les exemples de dashboards. Merci pour les liens !
emonplug c'est un emonTX avec moins d'entrées (une seule entrée CT et pas d'entrée température) ?
Pour les compteurs à LED, s'ils ont une sortie où on peut brancher un fil ça doit valoir le coup d'implémeter leur protocole de communication plutôt que de s'embêter avec la détection de LED.
Je savais même pas qu'il y avait de la doc en français. Je l'aurais proposée dans les liens de dépêche. Je suis incapable de la retrouver sans tes liens directs. Quel est le chemin logique ?
En fait le projet utilise plutôt la pince ampère-métrique, la lampe flash étant l'exception, je crois. D'ailleurs, j'ai un compteur à disque encore plus rustique qui n'a même pas de diode…
Merci pour l'info. Le document que tu cites spécifie le protocole de transmission. Je trouve moi aussi plus propre d'accéder directement aux valeurs du compteur si c'est possible.
J'ai vu récemment arriver quelques contributions d'utilisateurs qui amélioraient beaucoup l'efficacité du code (notamment en optimisant les requêtes en BDD), ce qui me laisse penser qu'il y a une marge d'amélioration ici pour quelqu'un qui aurait des compétences.
Conso de courant générale, a priori, oui (vérifie que tu as accès au câbles électriques près du compteur). Prises électriques, c'est quand même moins fait pour. Il faut réussir à passer le CT, ça fait une belle pince, ça ne rentre pas dans le boîtier de la prise. Ou alors il faut dégainer un câble de rallonge ou de multiprise. Si c'est sur un départ de compteur spécifique (un fusible séparé), envisager de mesurer au compteur. Sondes de températures, oui, bien sûr, c'est le plus simple.
Si en plus il est possible de regrouper une sonde de température et une mesure de courant, ça évite de multiplier les boîtiers. Pour juste une température, le TX est un peu "overkill" mais il est aussi vendu en version "température seulement".
N'hésite pas à venir poser des questions sur le forum si ça te tente.
[^] # Re: Equitable
Posté par jihele . En réponse au journal Fairphone, le smartphone du commerce équitable. Évalué à 7.
La version TF1/France2(/Max Havelaar ?) est une vision caritative : tu payes ton petit noir plus cher pour que le petit noir qui le cueille ait un peu plus de sous.
Pour d'autres, c'est la mise en place d'une économie alternative au capitalisme prédateur qui permette à chacun d'y trouver son compte à chaque maillon de la chaîne, en toute transparence, plutôt que de tirer la couverture et d'user de rapports de force pour écraser son prochain.
Il y a donc une vision caritative réductrice et une vision militante politique idéaliste.
D'un côté on dit au consommateur "tiens, achète-ça, c'est bien, tu auras la conscience tranquille, notre marque est la plus gentille et en plus c'est bon", de l'autre on lui dit "voilà ce qu'on a essayé de faire, c'est pas encore parfait, voilà où on en est, voilà l'impact que ça a sur les communautés, on est en train d'essayer de faire mieux, et on réfléchit à un commerce équitable nord-nord".
Il est clair que si on considère une pub pour un produit labellisé Max Havelaar vendu à Carrefour, le projet politique est difficile à retrouver. Il est absent de la communication. En revanche, on fait du volume et certains diront que les idéalistes qui font du travail de proximité et créent des filières qui approvisionnent le petit magasin du centre ville ont un impact beaucoup plus faible. Du volume, mais à quel prix ?
Oui, les supermarchés enfreignent régulièrement le droit, au même titre que beaucoup d'employeurs (et d'employés) et parfois même que la petite boutique du coin, au sein de laquelle la présence syndicale doit être en plus inexistante, rien n'est parfait. D'ailleurs pour éviter d'avoir à l'enfreindre, ils l'écrivent (ANI). En tout cas le fait est qu'ils ne cherchent qu'à maximiser un profit, en tirant les coûts vers le bas (pression côté producteur) et en vendant cher les produits bio/équitables (niche à destination des gens qui sont prêts à mettre plus cher, autant en profiter).
Ce commentaire ne vise pas à diaboliser le Super U de Parthenay.
[^] # Re: apt-get
Posté par jihele . En réponse au message Probléme d'installation avec Apt-get ou Aptitude. Évalué à 1.
Peut-être prendre les choses une par une. En attendant la migration Squeeze -> Wheezy (à faire dans un environnement stable et avec du temps devant soi), je m'amuserais pas à introduire des paquets Wheezy pour résoudre une problème, sauf à être certain de ce que je fais.
Dans le log, il doit y avoir une trace des opérations précédentes, aussi.
[^] # Re: Irlande ?
Posté par jihele . En réponse à la dépêche Gouvernement français et logiciels libre : du bon et du moins bon. Évalué à 3.
D'accord sur le fond mais je crois que ce que veut dire Ken Thompson, c'est qu'il est capable d'intégrer du code malveillant (backdoor ?) dans le code qu'il te livre, avec suffisamment de finesse pour que tu ne le voies pas à la relecture avant de le compiler toi-même.
Ce qui peut se comprendre. S'il suffit d'un débordement de buffer bien placé pour passer root sur une machine, il est alors facile de proposer un système avec une faille volontaire qui passe inaperçue.
C'est plus difficile de proposer un linux personnalisé avec une faille volontaire, puisque seuls les patches seraient à contrôler en priorité. Alors que des milliers ou millions de lignes de code Windows sans versionnement, c'est sans doute compliqué à auditer.
[^] # Re: Les autres noms remarquables
Posté par jihele . En réponse au journal Où il est question de D3, des communes de France et des performances SVG des moteurs de rendu. Évalué à 2.
http://ssz.fr/fr/#castel/ch%C3%A2teau/
http://ssz.fr/fr/#ville$/heim$/
Merci pour le journal et le boulot. C'est sympa et le rendu est super propre.
[^] # Re: La guerre des écosystèmes continue
Posté par jihele . En réponse au journal Google Hangouts remplace Talk: la fin de la fédération XMPP ?. Évalué à 2.
Je ne connaissais pas Jitsi.
Site officiel : https://jitsi.org/
Page ubuntu.fr : http://doc.ubuntu-fr.org/jitsi
Discussion sur l'intégration à Debian (le dernier message date un peu) :
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627362
Des infos plus récentes sur l'intégration à Debian :
http://mentors.debian.net/package/jitsi
Les bugtrackers sont souvent intéressant à lire. On comprend (en partie) pourquoi l'intégration d'un logiciel n'est pas si évidente, même si l'auteur fournit un .deb.
[^] # Re: root-exploit-sur-les-noyaux-linux
Posté par jihele . En réponse à la dépêche Root exploit sur les noyaux linux 2.6.38 à 3.8.8. Évalué à 1.
http://packages.qa.debian.org/l/linux.html
Apparemment, en debian stable c'est corrigé mais en testing ? Pourquoi est-ce que le fix n'est pas présent sur la branche testing ?
Parce qu'on attend la 3.8 de unstable qui arrive pas ?
Parce que quand on est en testing on doit aussi avoir une référence à stable-sec dans son sources.list de sorte que le paquet corrigé a priorité ? C'est quoi la ligne qui correspond ? Moi, j'ai ça, et je vois pas de 3.2.41-2+deb7u2 dans aptitude.
# Merci
Posté par jihele . En réponse à la dépêche Les gagnants du concours LinuxFr.org sur Linux Embarqué. Évalué à 2.
Merci pour cette initiative. Ça fait longtemps que je voulais écrire une dépêche pour présenter le projet OEM. L'occasion a fait le larron et ça m'a un peu boosté pour publier, sinon je serais encore en train d'attendre des résultats sympas à monter ou la nouvelle fonctionnalité qui tue.
La dépêche a donné un peu de visibilité francophone au projet et a suscité au moins une vocation : un DLFPien bâtisseur et enthousiaste qui a rejoint le projet pour instrumenter sa future maison.
[^] # Re: Glisser vers le haut ??
Posté par jihele . En réponse à la dépêche Firefox habite au 21. Évalué à 2.
La phrase laisse entendre que c'est la barre de recherche qui est Gtk, mais l'auteur a peut-être voulu parler de la barre de défilement.
[^] # Re: OpenStreetMap et simulation de vol
Posté par jihele . En réponse à la dépêche OpenStreetMap : pourquoi vous devriez l'utiliser. Évalué à 3.
Merci pour ces images !
Je n'ai jamais été attiré par les simulateurs de vol, que j'assimile soit à des "jeux d'avion", soit à des trucs compliqués super réalistes.
Mais j'ai toujours eu dans l'idée quand j'étais gamin qu'un jour on aurait une représentation du monde assez précise pour faire des jeux d'avion en monde réel et ça, ça change tout. Avec ces captures d'écran, j'ai l'impression qu'on en prend le chemin, ça fait envie.
Quand on navigue sur une carte sur internet, on s'en approche, mais c'est moins sympa.
[^] # Re: Debian 8
Posté par jihele . En réponse à la dépêche Debian : Épisode VII. Évalué à 2.
Oui, j'ai recherché une source exacte, pas trouvé. Apparemment c'est plus vrai depuis longtemps, tant mieux.
Il me semblait que l'état "installé automatiquement" était stocké dans une base de donnée propre à aptitude, pas à dpkg. Et donc bazar si on mélange les deux.
J'ai commencé avec Ubuntu/Synaptic et je trouvais ça pas mal. Autant je suis fan d'aptitude en ncurse, autant je persiste à dire que c'est précisément le genre d'interface qui fait fuir un débutant, que ça soit l'apparence, les raccourcis, etc. Synaptic a aussi une interface de gestion des dépôts qui évite de devoir éditer sources.list à la main. Et je me vois pas proposer un linux à un débutant s'il n'y a pas un truc comme ça. Et l'applet de mise à jour automatique (update-notifier).
Je préfère moi aussi l'interface ncurse d'aptitude à une ligne de commande apt-get ou aptitude. L'avantage de la ligne de commande est qu'elle se copie facilement sur un forum.
Je sais pas, mais l'installeur par défaut me semble pas mal et permet à un débutant d'installer et d'avoir un système joli qui tourne. Sous réserve de comprendre qqchose à Gnome Shell (moi j'y comprends rien), ou a un autre bureau de son choix, il peut se débrouiller. Donc autant avoir un système complètement "accessible".
Si je dois installer un linux chez un proche, j'hésite entre stable/Xfce et testing/Xfce, selon son expertise, son besoin de bleeding-edge, et ma proximité.
[^] # Re: Debian 8
Posté par jihele . En réponse à la dépêche Debian : Épisode VII. Évalué à 1.
C'est une bonne nouvelle (enfin c'est peut-être nouveau que pour moi…). Ça veut dire qu'on peut installer une Debian avec Synaptic chez un débutant et intervenir dessus en utilisant aptitude sans mettre le bazar.
Merci pour l'info.
[^] # Re: Debian 8
Posté par jihele . En réponse à la dépêche Debian : Épisode VII. Évalué à 1.
Je n'ai jamais testé mais j'ai lu précisément le contraire ! Attention. (Ça doit pas être trop dur à tester…)
Je ne l'ai jamais trouvé lent. Jusqu'à ce que je l'utilise sur un Raspberry Pi. Sur mon PC le tri se fait rapidement et j'ai très vite la main après le lancement.
Multi-arch j'utilise pas, mais ça doit faire partie des options manquantes au même titre que le tri par dépôt. Ça devrait pas être si compliqué à rajouter.
Je comprends qu'il ne soit pas recommandé : l'approche est peut-être de préconiser Synaptic et de laisser les plus expérimentés passer à apt-get en ligne de commande, qui partage la gestion de dépendances auto de Synaptic.
Je n'utilise aptitude presque qu'en mode ncurse et je le préfère à Synaptic, justement. Et puis ça a le mérite de me faire la même interface sur le PC que sur le serveur et le Rapsberry Pi. Mais on peut pas proposer ça a un débutant si on veut le garder. Pas tout de suite.
[^] # Re: Debian 8
Posté par jihele . En réponse à la dépêche Debian : Épisode VII. Évalué à 2.
Je crois que ça a été le cas (pour Wheezy, je crois) du fait de limitation d'apt-get sur la gestion des dépendances en particulier mais que ça ne l'est plus car ces limitations n'existent plus. Ce serit donc à nouveau apt-get qui serait recommandé.
J'utilise aptitude aussi et maintenant que j'ai commencé je le garde pour conserver l'état "installé automatiquement" de mes paquets, même si je change de version de distro. En tout cas tant qu'aptitude est maintenu.
C'est quand même pratique, aptitude, puisqu'à la fois rapide et puissant. Il manque quelques filtres automatiques (tri par dépôt d'origine, par exemple), mais ça reste bien.
[^] # Re: Ode à OSM !
Posté par jihele . En réponse au journal OpenStreetMap : pourquoi vous devriez l'utiliser. Évalué à 2.
Effectivement, je n'y avais pas pensé. Et ça saute aux yeux si on zoome et qu'on constate que le point se trouve juste à côté d'une route. La projection est effectivement une bonne solution évidente et générique.
Pour les villes, ça marchera bien si les noeuds "nom de ville" sont placés à un endroit pertinent sur la carte.
Ça pourrait à la limite coincer si les règles de placement des noms de ville selon OSM (à Bordeaux, c'est à côté de la place Gambetta, je sais pas pourquoi, à Toulouse c'est au Capitole, l'hôtel de ville) diffèrent de celles que l'on aimerait pour un calcul d'itinéraire (mairie pour coller aux panneaux routiers ?), mais c'est déjà plus de l'ordre du détail.
[^] # Re: Ode à OSM !
Posté par jihele . En réponse au journal OpenStreetMap : pourquoi vous devriez l'utiliser. Évalué à 2.
OK je comprends. Ton contournement doit fonctionner, mais ça fait partie de ces petits détails qui rendent le sites de calcul d'itinéraire depuis OSM moins agréables à utiliser. J'ai beau vouloir faire de la résistance, il faut reconnaître que Google Maps c'est super fluide.
Là c'est embêtant parce que je crois que la solution nécessite intervention sur les cartes OSM elles-mêmes, pas seulement au niveau du serveur de calcul d'itinéraire :
Cet endroit pourrait être la mairie, qui est en général desservie par le réseau routier et de transports en commun. C'est peut-être d'ailleurs ce point qui est utilisé pour déterminer la distance à une ville (panneaux routiers).
J'ai bien conscience que la bonne réponse à la question "combien de temps de Bordeaux à Limoges ?" est "Ben ça dépend, tu pars de quel endroit à Bordeaux ?" mais c'est quand même un besoin courant. Et ça n'empêche pas d'affiner après en déplaçant les indicateurs de départ et d'arrivée.
[^] # Re: 2 alternatives plus souples
Posté par jihele . En réponse à la dépêche Programmez votre Raspberry Pi depuis le confort de votre navigateur Web - et en JavaScript!. Évalué à 1.
C'est aussi comme ça que je fais et ça me convient bien pour coder de n'importe où.
Ceux qui n'ont pas un accès SSH régulier (proxy bloquant) peuvent tester ajaxterm mais je crains que ça rame un peu.
[^] # Re: excellente plateforme, très peu chére et facile d'accès, LOL WUT
Posté par jihele . En réponse à la dépêche Programmez votre Raspberry Pi depuis le confort de votre navigateur Web - et en JavaScript!. Évalué à 3.
Vu sur DLFP : OlinuXino
Il y a différents modèles. A chacun de se faire une idée des différences avec le Pi.
[^] # Re: Ode à OSM !
Posté par jihele . En réponse au journal OpenStreetMap : pourquoi vous devriez l'utiliser. Évalué à 1.
J'utilise souvent OSRM.
Par rapport à Google Maps, je regrette que
Pour être honnête, je le trouve bien moins réactif que celui de Google. Et les heures de trajet indiquées sont plus fantaisistes.
Je ne connaissais pas mapquest, je viens d'essayer :
[^] # Re: Attention: postgresql
Posté par jihele . En réponse à la dépêche Debian : Épisode VII. Évalué à 3.
La dernière fois que j'ai fait ça, pour une mise à jour mineure, j'ai eu un petit problème.
Le script de mise à jour est chargé d'arrêter le vieux cluster, mais chez moi, il n'y parvenait pas. Je pouvais l'arrêter moi-même avec l'option --force, mais il faut que le script le fasse lui-même parce qu'il a des choses à demander au cluster avant. En gros.
J'ai donc modifié /usr/bin/pg_upgradecluster pour remplacer le timeout par un force:
et ça a fonctionné.
Le script de mise à jour a été modifié pour pouvoir fonctionner avec un cluster arrêté (il le redémarre avec une connexion restreinte). Ça permet de l'arrêter à la main avec --force avant, dans le cas où le script n'y arrive pas avec l'option timeout.
Voir ce rapport de bogue : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681344
La version de postgresql-common qui contient cette modif (la version 135) n'est pas encore dans Wheezy : http://packages.qa.debian.org/p/postgresql-common.html
[^] # Re: Licences
Posté par jihele . En réponse à la dépêche OpenEnergyMonitor : outils open-source de suivi énergétique. Évalué à 2.
Je comprends. C'est clairement pas le priorité des développeurs que de réfléchir à ça (cf. les commentaires en bas de cette page). Je signale ça à Trystan. Merci.
[^] # Re: Merci!
Posté par jihele . En réponse à la dépêche OpenEnergyMonitor : outils open-source de suivi énergétique. Évalué à 2.
Je ne suis pas fan non plus. Quand on peut passer un fil, je préfère. Ce n'est pas l'optique choisie par le projet. Sans doute pour pouvoir s'adapter à l'existant. Selon la grandeur que tu cherches à mesurer, tu peux reproduire un peu la même chose avec un arduino et un shield ethernet.
Je crois que la prochaine version du TX prévoit un emplacement vide pour un connecteur Xbee optionnel (radio toujours) mais rien pour de l'ethernet.
Dans une maison neuve, tu peux passer du RJ45 partout donc c'est intéressant pour toi de regarder vers là, en effet. En bon geek, j'en mettrais un peu plus que le minimum (par exemple des prises à deux ports dans chaque pièce) histoire d'être tranquille.
Ce genre de chose est possible, oui. Dans la config de base, non, c'est un seul port pour ça par emonTX. Ca vaudrait le coup de prendre un arduino + shield ethernet et faire un truc à plusieurs ports (temp, lum, humidité). C'est pas forcément la mort en s'inspirant des docs du site, vraiment. Jette un coup d'oeil à la page Building Blocks qui détaille les morceaux. Et n'hésite pas à intervenir sur le forum si tu es intéressé, tu ne serais pas le seul.
Comme la construction doit déjà pas mal te mobiliser, je doute que tu aies des masses de temps pour développer ça, mais pense aux ports éthernet partout, tu auras toujours le temps de voir. Côté EDF, je ne sais pas s'il y a le choix pour le compteur et si ça vaut le coup de se renseigner avant pour en choisir un avec une sortie plus pratique à récupérer.
Oui, ce n'est pas grand chose à modifier. Comme je le dis en dépêche c'est assez modulaire.
Tu penses à une implémentation perso de zéro ? Je n'ai pas essayé les alternatives citées dans la dépêche, mais regarde du côté de ThingSpeak, par exemple, et dis-nous ce que ça donne.
[^] # Re: Merci!
Posté par jihele . En réponse à la dépêche OpenEnergyMonitor : outils open-source de suivi énergétique. Évalué à 2.
Salut.
J'avais cherché ton nom sur DLFP avant de poster. Bienvenu à toi. Je sais pas si tu as fait attention, mais je mentionne vos contributions dans la dépêche, dans les exemples de dashboards. Merci pour les liens !
emonplug c'est un emonTX avec moins d'entrées (une seule entrée CT et pas d'entrée température) ?
Pour les compteurs à LED, s'ils ont une sortie où on peut brancher un fil ça doit valoir le coup d'implémeter leur protocole de communication plutôt que de s'embêter avec la détection de LED.
Je savais même pas qu'il y avait de la doc en français. Je l'aurais proposée dans les liens de dépêche. Je suis incapable de la retrouver sans tes liens directs. Quel est le chemin logique ?
[^] # Re: Merci!
Posté par jihele . En réponse à la dépêche OpenEnergyMonitor : outils open-source de suivi énergétique. Évalué à 2.
En fait le projet utilise plutôt la pince ampère-métrique, la lampe flash étant l'exception, je crois. D'ailleurs, j'ai un compteur à disque encore plus rustique qui n'a même pas de diode…
Merci pour l'info. Le document que tu cites spécifie le protocole de transmission. Je trouve moi aussi plus propre d'accéder directement aux valeurs du compteur si c'est possible.
[^] # Re: Licences
Posté par jihele . En réponse à la dépêche OpenEnergyMonitor : outils open-source de suivi énergétique. Évalué à 4.
C'est autonome.
J'ai vu récemment arriver quelques contributions d'utilisateurs qui amélioraient beaucoup l'efficacité du code (notamment en optimisant les requêtes en BDD), ce qui me laisse penser qu'il y a une marge d'amélioration ici pour quelqu'un qui aurait des compétences.
[^] # Re: Merci!
Posté par jihele . En réponse à la dépêche OpenEnergyMonitor : outils open-source de suivi énergétique. Évalué à 3.
Pas simple, mais pas impossible non plus.
Conso de courant générale, a priori, oui (vérifie que tu as accès au câbles électriques près du compteur). Prises électriques, c'est quand même moins fait pour. Il faut réussir à passer le CT, ça fait une belle pince, ça ne rentre pas dans le boîtier de la prise. Ou alors il faut dégainer un câble de rallonge ou de multiprise. Si c'est sur un départ de compteur spécifique (un fusible séparé), envisager de mesurer au compteur. Sondes de températures, oui, bien sûr, c'est le plus simple.
Si en plus il est possible de regrouper une sonde de température et une mesure de courant, ça évite de multiplier les boîtiers. Pour juste une température, le TX est un peu "overkill" mais il est aussi vendu en version "température seulement".
N'hésite pas à venir poser des questions sur le forum si ça te tente.