jihele a écrit 1238 commentaires

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.

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.

J'utilise souvent OSRM.

Par rapport à Google Maps, je regrette que

• la recherche est beaucoup plus capricieuse
• il est moins réactif au recalcul d'itinéraire (si on déplace la courbe de trajet)
• les temps de trajet affichés sont un peu fantaisistes

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 :

Nous ne trouvons pas d'itinéraire de Limoges, Limousin 87000 à Bordeaux, Aquitaine 33000;33100;33200;33300;33800.

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.

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

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.

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 ?

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.

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.

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.

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 bon ou j'ai raté un épisode ?

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.)

Il est évident que c'est lui qui ne mentionne pas la distribution pour éviter le troll, pas l'article original !

Pour quelqu'un qui ne connaissait pas l'auteur, c'était pas évident, d'autant que sa tournure est un peu maladroite.

Maintenant, je le connais…

Heureusement que tu es intervenu pour y mettre un terme.

Pour éviter un troll la distribution n'a pas été mentionnée. Mais bon, Linux reste Linux

Alors soit tu as mal lu, soit c'est moi qui ai lu beaucoup trop en diagonale, mais je vois 13 occurrences de "Suse" dans l'article dont une dans le titre : "Asia’s oldest stock exchange has saved huge costs by deploying SUSE Linux for powering a majority of its applications"

De toute façon, dès lors qu'il y a pas écrit GNU/Linux, il reste matière à débat. On pourra en reparler demain.

Effectivement, ça n'est pas prévu pour tous les modèles.

        def system_info(self):
            '''
            Do a check if the notebook is a m1730 or not.
            Then adjust the labels to the correct model.
            '''

            info = self.xpslc.SystemInfo()
            # m1730 = MXG071
            # m1710 = MXG061
            # Other = ??? (Use same labels as m1710)
            if "MXG071" in info:
                print "Found the XPS m1730, setting correct labels..."
                self.labelFans.set_label("Touchpad")
                self.labelSpeakers.set_label("Speaker (Left)")
                self.labelBack.set_label("Speaker (Right)")
                self.labelTouchpad.set_label("Backpanel")
            else:
                print "Found an other model than the XPS m1730, setting correct labels..."
                self.labelFans.set_label("Fans")
                self.labelSpeakers.set_label("Speakers")
                self.labelBack.set_label("Backpanel")
                self.labelTouchpad.set_label("Touchpad")

Rhaaa, c'est malin. Maintenant, je suis tenté d'essayer d'ajouter le mien…

A noter que le truc dépend de libsmbios et libsmbios-bin. Ils sont appelés directement mais apparemment des bindings sont disponibles dans le dépôt experimental de debian.

Merci ! Je regarderai. Curieux que tout ces logiciels ne me soient pas apparus il y a un an lorsque je cherchais.

Merci pour le pointeur. Quelques infos ici :
http://doc.ubuntu-fr.org/alienfx

Notamment un pointeur vers un programme en python :
https://code.google.com/p/pyalienfx/

Pas sûr que ça fonctionne tel quel pour mon XPS, ni même que ça s'adapte, mais c'est fait pour Alienware, qui est quand même le sujet du journal au départ…

Bonne question.

J'ai une machine DELL (XPS 630i) et pour allumer/éteindre/choisir la couleur des diodes, il faut un utilitaire windows. Je ne crois même pas qu'il y ait de paramétrage BIOS. Donc c'est toujours allumé pour rien. Et c'est un sacré bordel à démonter, donc j'ai laissé tomber l'idée de les débrancher.

Je n'ai pas essayé de faire tourner l'utilitaire windows sous wine. Ni de hacker quoi que ce soit. Je suis un peu surpris en revanche de ne pas avoir trouvé de trace d'un projet visant à faire ça. Peut-être serait-il possible de tracer ce que fait le truc windows pour "l'ingénierie-inverser".

Voilà, je viens de trouver mon vieux message de forum :

https://linuxfr.org/forums/general-general/posts/nvidia-esa-enthusiast-system-architecture-linux

Le protocole qui sert à dialoguer avec les diodes sur mon PC est ESA (Enthusiast System Architecture), de nVidia. Je viens de regarder vite fait et je n'ai pas trouvé si c'était pareil sur le Alienware X51.

Donc à Yakuake fixé, Debian > Arch. Et par extension…

CQFD

bref ce sondage me parait inutile, surtout sous sa forme.

Il manque donc l'option

[] J'ai bien vu les boutons pertinent / inutile mais ça va mieux en le disant.

Mais ne le répétez pas.