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.
Les codes source du logiciel et les spécifications du matériel sont sous GPL.
Je ne me souviens plus si j'ai écrit ceci ou bien si ça fait partie de l'édition à la modération. En tout cas si ce n'est pas moi, je suis fautif car j'aurais du spécifier la licence.
Les licences sont précisées sur cette page. Le logiciel est sous GPL v3 et le matériel sous Creative Commons Attribution-ShareAlike 3.0.
Je ne crois pas que le choix des licences ait fait l'objet d'une réflexion poussée. La volonté était de faire du libre, point. Par exemple, la GPL v3 a du être choisie (plutôt que la v2) parce que c'est la dernière version.
En effet. Je ne sais pas où ça en est maintenant, mais il y a un an, je développais (pour bricoler) une petit application python /GTK (cf. journal) et je suis passé de pygtk à PyGObject.
Ça ne s'est pas fait sans mal parce que pygtk a été considéré comme déprécié alors que la doc de PyGObject n'était pas du tout au point. Et lorsque j'ai évoqué le sujet sur la trollinmailing-list, on m'a répondu qu'il fallait que je l'écrive si elle était incomplète…
Ceci dit, c'est clair que l'introspection est une excellente idée et un effort utile pour l'avenir.
Un autre bon point pour Qt, c'est le portage Windows. Côté Gtk, la dernière fois que j'ai regardé, il y a un an, c'était abandonné.
Je suis utilisateur de Xfce dont plutôt Gtk, mais entre les difficultés que j'ai éprouvées, mes lectures ici et autres conversations, si je devais partir de zéro demain, je pourrais m'orienter vers Qt. Tout ça m'inquiète d'ailleurs un peu pour l'avenir de Xfce.
Bah rien, DRM ou pas DRM si tu affiches un media sur l'écran de ton ordinateur il est fatalement enregistrable d'une manière ou d'une autre.
Dans le cas d'un téléphone, je n'ai pas trop de mal à imaginer un flux décodage DRM matériel -> carte graphique -> écran qui ne passe pas par du logiciel, ce qui me paraissait assez inconcevable avec les PC de bureau (puisqu'il faut bien passer par VGA/DVI/HDMI et il faudrait des écrans "complices").
Je ne vois pas comment introduire un DRM sans que ça nécessite du code obfusqué à un endroit. Il y a peut-être une réponse sur la dépêche de la pétition, je n'ai pas lu tous les commentaires.
Admettons que l'idée est de "protéger" une vidéo. S'il est possible de la lire avec un logiciel libre grâce à une clé telle que tu la décris, alors qu'est-ce qui empêche d'enregistrer la vidéo ?
L'engouement pour le flash (mis à part l'aspect pratique quand il n'y avais pas d'alternative) c'était ça : le lecteur n'est pas sous contrôle de l'utilisateur. Certes ont peut toujours agir en aval (screencast), d'où l'idée d'obfusquer le canal jusqu'à l'écran (informatique de confiance) avec des cartes graphiques et écrans complices. On pourra toujours filmer l'écran…
En général, faute de pouvoir rendre la copie impossible, les lobbies poussent pour la rendre compliquée, et ça suffit puisque pour l'immense majorité des gens, compliqué, c'est impossible. Même installer l'extension firefox qui fait le boulot peut être une barrière. Surtout si le prix à payer pour accéder au contenu n'est pas jugé élevé : un peu de pub, quelques ralentissements à cause de streaming.
Dans ce contexte, c'est pas simple de discuter technique puisque leur objectif n'est pas de faire quelque chose de propre et logique, mais un truc techniquement bancal qui ralentira une évolution qui ne leur plaît pas. Il leur suffit d'avoir toujours une longueur d'avance sur les outils de rip de vidéo, par exemple, même si c'est impossible de faire un truc propre véritablement sécurisé.
J'ai jamais compris ce qui empêchait de faire des ordis de bureau qui consommerait la même chose que des portables. Il suffit de mettre le même matériel, la contrainte de place en moins. Ça serait trop cher et pour le même prix les clients préfèreraient un portable ?
Ça me fait toujours un peu tiquer de voir des présentations de bâtiments HQE et compagnie où on met en avant l'utilisation d'ordinateurs portables au titre d'économie d'énergie alors que c'est moins évolutif dans le temps, et au final le bilan est peut-être pas meilleur.
Pourquoi pas des PC de bureau économes ?
(Une réponse partielle pourrait être que de toute façon les gens ont besoin d'un portable…, mais c'est le fait de présenter ça comme une mesure de sobriété énergétique qui me gêne.)
[^] # 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.
# Licences
Posté par jihele . En réponse à la dépêche OpenEnergyMonitor : outils open-source de suivi énergétique. Évalué à 6.
Je ne me souviens plus si j'ai écrit ceci ou bien si ça fait partie de l'édition à la modération. En tout cas si ce n'est pas moi, je suis fautif car j'aurais du spécifier la licence.
Les licences sont précisées sur cette page. Le logiciel est sous GPL v3 et le matériel sous Creative Commons Attribution-ShareAlike 3.0.
Je ne crois pas que le choix des licences ait fait l'objet d'une réflexion poussée. La volonté était de faire du libre, point. Par exemple, la GPL v3 a du être choisie (plutôt que la v2) parce que c'est la dernière version.
[^] # Re: Openshot se tire une balle dans le pied ... Ils font fausse route ;-)
Posté par jihele . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 6.
En effet. Je ne sais pas où ça en est maintenant, mais il y a un an, je développais (pour bricoler) une petit application python /GTK (cf. journal) et je suis passé de pygtk à PyGObject.
Ça ne s'est pas fait sans mal parce que pygtk a été considéré comme déprécié alors que la doc de PyGObject n'était pas du tout au point. Et lorsque j'ai évoqué le sujet sur la
trollinmailing-list, on m'a répondu qu'il fallait que je l'écrive si elle était incomplète…Ceci dit, c'est clair que l'introspection est une excellente idée et un effort utile pour l'avenir.
Un autre bon point pour Qt, c'est le portage Windows. Côté Gtk, la dernière fois que j'ai regardé, il y a un an, c'était abandonné.
Je suis utilisateur de Xfce dont plutôt Gtk, mais entre les difficultés que j'ai éprouvées, mes lectures ici et autres conversations, si je devais partir de zéro demain, je pourrais m'orienter vers Qt. Tout ça m'inquiète d'ailleurs un peu pour l'avenir de Xfce.
[^] # Re: DRM
Posté par jihele . En réponse à la dépêche Vers l'abandon de Silverlight et de Flash. Évalué à 1.
Dans le cas d'un téléphone, je n'ai pas trop de mal à imaginer un flux décodage DRM matériel -> carte graphique -> écran qui ne passe pas par du logiciel, ce qui me paraissait assez inconcevable avec les PC de bureau (puisqu'il faut bien passer par VGA/DVI/HDMI et il faudrait des écrans "complices").
[^] # Re: DRM
Posté par jihele . En réponse à la dépêche Vers l'abandon de Silverlight et de Flash. Évalué à 10.
Je ne vois pas comment introduire un DRM sans que ça nécessite du code obfusqué à un endroit. Il y a peut-être une réponse sur la dépêche de la pétition, je n'ai pas lu tous les commentaires.
Admettons que l'idée est de "protéger" une vidéo. S'il est possible de la lire avec un logiciel libre grâce à une clé telle que tu la décris, alors qu'est-ce qui empêche d'enregistrer la vidéo ?
L'engouement pour le flash (mis à part l'aspect pratique quand il n'y avais pas d'alternative) c'était ça : le lecteur n'est pas sous contrôle de l'utilisateur. Certes ont peut toujours agir en aval (screencast), d'où l'idée d'obfusquer le canal jusqu'à l'écran (informatique de confiance) avec des cartes graphiques et écrans complices. On pourra toujours filmer l'écran…
En général, faute de pouvoir rendre la copie impossible, les lobbies poussent pour la rendre compliquée, et ça suffit puisque pour l'immense majorité des gens, compliqué, c'est impossible. Même installer l'extension firefox qui fait le boulot peut être une barrière. Surtout si le prix à payer pour accéder au contenu n'est pas jugé élevé : un peu de pub, quelques ralentissements à cause de streaming.
Dans ce contexte, c'est pas simple de discuter technique puisque leur objectif n'est pas de faire quelque chose de propre et logique, mais un truc techniquement bancal qui ralentira une évolution qui ne leur plaît pas. Il leur suffit d'avoir toujours une longueur d'avance sur les outils de rip de vidéo, par exemple, même si c'est impossible de faire un truc propre véritablement sécurisé.
J'ai bon ou j'ai raté un épisode ?
[^] # Re: Généralement moins d'un dixième de secondes
Posté par jihele . En réponse au sondage mon ordinateur s'éteint en moins de.... Évalué à 1.
J'ai jamais compris ce qui empêchait de faire des ordis de bureau qui consommerait la même chose que des portables. Il suffit de mettre le même matériel, la contrainte de place en moins. Ça serait trop cher et pour le même prix les clients préfèreraient un portable ?
Ça me fait toujours un peu tiquer de voir des présentations de bâtiments HQE et compagnie où on met en avant l'utilisation d'ordinateurs portables au titre d'économie d'énergie alors que c'est moins évolutif dans le temps, et au final le bilan est peut-être pas meilleur.
Pourquoi pas des PC de bureau économes ?
(Une réponse partielle pourrait être que de toute façon les gens ont besoin d'un portable…, mais c'est le fait de présenter ça comme une mesure de sobriété énergétique qui me gêne.)