Quand un changement de paradigme survient il repose toujours sur un changement des fondamentaux constructivistes. C’est à dire qu’il définit des objets qui n’ont aucune possibilité de pouvoir être décrits par l’ancien paradigme. Ainsi la Relativité Générale d’Einstein, décrivant l’espace-temps comme courbe, ignore la notion de forces présentes dans la physique Newtonienne, laquelle physique repose sans le dire sur un espace euclidien. Un Newtonien ne pouvait avoir cette idée en tête, car il interprétait la réalité comme étant implicitement inscrite dans un espace dont il n’imaginait même pas qu’on puisse le penser autrement.

Or donc quand un tenant de la Théorie Relative de la Monnaie, voit le système monétaire, il voit que c’est ce même système monétaire qui est le problème, dans sa structure implicite non-remise en question, qui ne tient pas compte des 4 libertés économiques et du remplacement générationnel des hommes dans le temps. Il voit parfaitement comment cette structure fait qu’une monnaie prétendue commune n’est en réalité pas commune du tout, mais constitue en soi, par sa structure même, un privilège au bénéfice des uns au détriment des autres, ou encore un bénéfice pour certaines générations d’hommes au détriment d’autres générations.

A contrario, ce même tenant de la TRM voit et comprend que des approches constructivistes, tentant de valider ou de critiquer la notion de Revenu de Base, sont dans la non-compréhension de la nature même de la structure monétaire comme cause. Comme dans cet article de Michel Leis « Revenu Universel et partage » sur le blog de Paul Jorion ou bien encore ce débat en 4 épisodes entre Marc de Baquiat et Guillaume Allègre économiste à l’OFCE, ou encore cet article d’Olivier Berruyer « Idée reçue : “L’austérité en Angleterre marche ! ».

Car quel est le problème fondamental implicitement non-compris dans ces approches !? C’est de ne pas intégrer la structure du système monétaire dans lequel ils développent leurs analyses. Le constructivisme de ce système monétaire non-libre implique forcément des notions de valeurs ou de non-valeurs, définis implicitement comme absolues, non-relatives, concepts fondamentaux et implicites desquels découlent leurs analyses.

Ainsi voyons par point de vue la réfutation relativiste correspondante :

Michel Leis :

« …en l’état actuel, le travail des hommes reste une composante importante de la valeur ajoutée. La disparition progressive d’une partie de l’emploi en Occident n’implique pas pour autant que l’emploi tende vers le zéro absolu… »

Réponse relativiste : Le travail est une notion individuelle non-absolue qui n’a aucun lien en soi avec la notion d’emploi = un travail défini par un employeur pour autrui = un privilège en terme de définition = un point de vue relatif comme un autre. Une théorie économique bien fondée ne peut donc aucunement intégrer un type de relation particulière et non-généralisable comme fondement de raisonnement. Les hommes produisent des valeurs dont ne sont pas juges les autres hommes, et ceci indépendamment de toute notion d’emploi ou même d’échange économique préalable. La production de valeurs par l’homme participe dans l’instant même et participera l’instant suivant jusque après sa mort de la base de l’économie.

Claude Allègre :

« Toutefois, il est difficile de justifier un revenu inconditionnel, versé à tous de manière égalitaire, par les contributions sociales fondamentales réalisées par certains : quid de ceux qui ne gardent pas les enfants et ne participent pas au travail associatif ?

Réponse relativiste : Ici le tenant de la théorie économique non-libre se place directement lui-même en tant que celui qui définit ce qui produit de la valeur ou pas, ou encore suppose qu’autrui puisse juger de ce qu’un homme participe ou non de la production de valeur « ceux qui ne participent pas… ». Or la croyance en cette possibilité de définir « la participation » ou la « non-participation » nie bien entendu toute la nature même de l’innovation. Il est quasi certain qu’au moment où ce billet a été publié sur une plateforme utilisant des logiciels libres, une valeur fondamentale produite il y a 31 ans par Richard Stallman, que Mr Allègre n’a jamais rémunéré le travail des producteurs et fondateurs des valeurs libres qu’il utilise pour naviguer et publier sur l’internet. Ainsi cette non-reconnaissance d’autrui comme son semblable participe d’une vision de l’économie où il est impossible de comprendre que Debian vaille 14 milliards d’euros alors que déjà certains parmi ses fondateurs et contributeurs sont déjà morts à présent sans jamais avoir vu le début du commencement d’une monétisation de leur production de valeur ramassée pour l’essentiel par d’autres, des années plus tard (et donc bien des morts plus tard). Il y a aussi ici une confusion entre monnaie et « revenu » qui dans ce paradigme non-libre, suppose pour le « revenu » quelque chose, alors que dans un paradigme libre, « monnaie » ne signifie pas de « quelque chose » d’autre que « monnaie ». La non-dissociation de « monnaie » et de « revenu » participe ici aussi de l’incapacité à intégrer la notion de monnaie-libre, ou de valeur libre tels que Bitcoin ou OpenUDC.

Pour résumer, l’innovation du temps présent est forcément invisible des contemporains, sinon ce ne peut être de l’innovation par définition. Seule une théorie économique qui ne comprend pas que les hommes naissent vivent et meurent, peut implicitement postuler à tort que les valeurs produites par les hommes puisse jamais être toutes reconnues de leur vivant, et donc monétisées de leur vivant. Seules quelques très rares valeurs produites suivent ce chemin, la plupart ne monétisant qu’après leur mort que des bénéficiaires illégitimes au sein de systèmes monétaires non-libres. Guillaume Allègre serait donc bien en peine d’apporter quelque preuve de ğvaleur que ce soit, puisque implicitement il croit qu’il est possible de connaître a-priori la notion de valeur, voire il postule implicitement qu’un homme ne produit pas de valeur a-priori, puisqu’il se positionne, pour la monnaie, en tant que juge a-posteriori de son semblable passé ou contemporain, ignorant sa propre mort et le nombre de ses contemporains qu’il ignore ainsi que leurs successeurs.

Olivier Berruyer :

« Rôôôôô qu’elle est belle l’austérité à 6 / 8 % du PIB de déficit public ! Pour avoir moins de 2 % de croissance du PIB ! 35 Md€ de croissance avec 130 Md€ de déficit – quel rendement extraordinaire ! »

Réponse relativiste : Ici l’analyse se perd en conjectures sur une pensée qui s’attache implicitement à des données qui ne représentent qu’une projection d’un phénomène non-critique provenant du passé, et ceci à cause du fondement implicite faux, qui donne au PIB une réalité économique alors qu’il n’est qu’une apparence sans fondement.

Or le PIB ne représente qu’une seule et même chose, la circulation de monnaie entre acteurs économiques. Si donc par exemple des producteurs de valeurs économiques décident pendant 10, 20 ou 30 ans, d’être autonomes, de la façon qui leur convient, de produire sans rien échanger pendant cette durée, alors bien que la production augmenterait partout, le PIB s’effondrerait. Et alors quoi ? Dans cette approche économique non-libre il faudrait ne pas monétiser ces acteurs économiques en face de la valeur produite par eux, car seule la matérialisation des échanges économiques sous forme comptable dans l’unité monétaire non-libre de référence fait foi pour créer de cette monnaie non-libre depuis son centre d’émission illégitime.

Et si au bout de cette période de 10, 20 ou 30 ans, les producteurs économiques décident de s’échanger leur production, la rareté monétaire induite pendant cette même durée implique qu’ils doivent le faire via le troc, absolument pas le biais d’une monnaie qui ne représente plus que ce qui était le temps passé, le temps où leurs prédécesseurs étaient encore vivant. Ici donc nous avons l’ignorance implicite d’un double effet de la résonance psychologique, racine du cycle non-libre, augmenté de l’ignorance du flux temporel humain. Les générations montantes n’ont pas, n’ont jamais eu, et n’auront jamais, de devoir implicite ou explicite de se laisser entraîner par les choix de leurs aînés, que ce soit en regard d’une prétendue « dette » ou en regard d’un prétendu « Produit Intérieur Brut », les deux n’ayant aucune existence devant leurs propres choix.

Pour conclure, à cause de cette impossibilité de compréhension qui repose sur le choix d’un paradigme non-libre, qui ne reconnaît pas les hommes comme semblables, ni dans l’espace ni dans le temps, en adoptant une définition implicite et arbitraire de ce qui est valeur ou non-valeur, il n’est pas de possibilité au sein de cette ignorance de démontrer le Revenu de Base. Tout comme, en revenant sur un paradigme déjà explicité et ré-explicité ici-même, il n’est guère de possibilité de démontrer au sein d’une géométrie euclidienne l’existence de triangles dont la somme des angles est supérieure à 180°, car il faut changer de fondement pour cela.

C’est pour cela qu’on ne verra pas d’analyse de ces auteurs comprenant l’émergence d’une valeur libre telle que celles que nous avons citées préalablement, et qu’ils utilisent pourtant pour publier leurs raisonnements tout en ignorant superbement les producteurs de ces valeurs morts depuis les 40 dernières années. Tout comme comme on ne verra pas d’analyse de ces mêmes auteurs concernant l’émergence de monnaies libres ou non-libres telles que Bitcoin, OpenUDC, uCoin, Monnaie M, Freicon, iOpen, Cyclos etc… indépendantes de leurs définitions implicites de ce qui est travail ou non-travail, valeur ou non-valeur, car ces phénomènes ne peuvent pas être compris dans leur espace nominatif et formel (conceptuel).

Aussi celui qui comprend l’essence de ce principe ne tient pas à convaincre les euclidiens que la géométrie non-euclidienne est « vraie », car elle ne s’impose pas non plus, mais elle se choisit parce qu’elle est jugée comme donnant de meilleurs effets tout en réduisant les effets indésirables. Aussi un véritable tenant de la Théorie Relative de la Monnaie ne tient pas à transformer à tout prix une monnaie non-libre dominante en monnaie libre, il laisse la liberté de ceux qui l’ont choisie, de continuer à utiliser cette non-liberté qu’ils estiment bonne pour eux-mêmes, tout comme l’homme de science ayant compris la portée des géométries non-euclidiennes laisse les euclidiens jouir de leur géométrie unique puisqu’ils se trouvent bien dans cette unicité et n’ont pas même l’idée qu’il puisse en être autrement.

Pour ce qui les concerne, les relativistes, tenants d’une économie libre et donc d’une monnaie libre développent, adoptent et utilisent un système monétaire libre tel que OpenUDC, uCoin, ou MonnaieM, en réfutant tout privilège et tout arbitraire, en réfutant toute définition de valeur autre que l’homme lui-même dans leurs fondements monétaires, en adoptant le principe de relativité de toute valeur qui implique que seul l’homme définit pour lui-même ce qu’il estime valeur ou non-valeur.

Original post of Stéphane Laborde.Votez pour ce billet sur Planet Libre.

Il est parfois nécessaire de contrôler le taux d’occupation de la mémoire vive sur sa machine , afin de détecter les programmes ou les processus monopolisant trop de ressources. Cela peut nous permettre de remédier à un éventuel ralentissement et d’optimiser notre système, afin que celui-ci reste véloce. Les outils permettant de le faire sous GNU/Linux sont assez nombreux, à commencer par le terminal qui d’un simple ps, top ou htop s’il est installé, nous dira tout ce que l’on doit savoir. Si toutefois vous êtes de nature curieuse et que vous aimez bien tester de nouvelles choses, ps_mem est un petit utilitaire écrit en Python dont le but est de permettre aux utilisateurs de voir le taux d’occupation de leur mémoire vive (RAM), occasionné par les programmes et processus en cours. Si ça vous intéresse nous allons voir comment l’installer sur votre distribution GNU/Linux et comment l’utiliser.

Installer ps_mem sur votre distribution GNU/Linux :

Au niveau de l’installation il n’y a rien de bien compliqué et c’est à peu près identique sur toutes les distributions GNU/Linux.  Trois lignes de commande feront l’affaire.

Commencez par ouvrir un terminal et entrez la commande suivante pour télécharger le script :

wget https://raw.github.com/pixelb/ps_mem/master/ps_mem.py

Ensuite entrez ceci pour le copier dans le bon répertoire :

sudo cp ps_mem.py /usr/local/sbin/mem

Et enfin, finissez en lui attribuant les droits qui vont bien :

sudo chmod 755 /usr/local/sbin/mem

Utilisation :

Niveau utilisation il n’y a pas non plus de grandes difficultés, car une seule commande peut suffire.

Pour afficher les informations de manière basique, entrez ceci dans votre terminal :

Exemple :

sudo mem

Vous devriez alors avoir un retour qui ressemble à celui-ci (que j’ai un peu raccourci pour l’occasion), où les processus et le la quantité de mémoire qu’ils occupent sont clairement indiqués. On ne peut pas faire plus simple et plus clair :

lavachelibre@lavachelibre-labs:~$ sudo mem
Private + Shared = RAM used Program

11.4 MiB + 6.1 MiB = 17.4 MiB Xorg
19.1 MiB + 3.4 MiB = 22.5 MiB nautilus
24.1 MiB + 799.0 KiB = 24.8 MiB evolution-calendar-factory
24.1 MiB + 8.2 MiB = 32.3 MiB python2.7 (3)
48.8 MiB + 3.7 MiB = 52.5 MiB shutter
55.7 MiB + 5.2 MiB = 60.9 MiB gnome-shell
554.2 MiB + 50.8 MiB = 605.0 MiB chromium-browser (12)
———————————
946.8 MiB
=================================
lavachelibre@lavachelibre-labs:~$

Voici également ce que ça donne en image :

Outre l’utilisation de base, vous pouvez également utiliser quelques arguments dont l’option -w suivie de la valeur de votre choix, 10 par exemple, qui vont vous permettre de relancer automatiquement la commande toutes les 10 secondes.

Exemple :

sudo mem -w 10

Pour obtenir la liste complète des options, vous pouvez vous servir de l’argument -h :

Exemple :

sudo mem -h

Pour le reste je ne vous le cache pas, peu d’options sont disponibles et Ps_mem en est encore à un stade de développement assez basique. Je ne sais pas si vous allez le trouver utile, mais il a le mérite d’être là et de faire ce pour quoi il a été écrit. Pour le reste il va falloir attendre de voir comment il évolue avant de se prononcer.

Si vous avez envie d’en savoir plus et de garder un œil sur le projet, il suffit de vous rendre sur la page Github qui lui est dédiée.

Amusez-vous bien.

source

Original post of La vache libre.Votez pour ce billet sur Planet Libre.

L’objectif de ce billet est de parvenir à lire le flux provenant de la caméra d’un Raspberry Pi avec un décalage de quelques secondes (plutôt qu’en direct), avec les outils dédiés que sont raspivid et omxplayer.

Contexte

Là où je travaille, il y a un babyfoot. Nous avons récemment décidé de l’informatiser un peu pour avoir la détection et le ralenti des buts. Entre autres, un Raspberry Pi a été installé avec sa caméra au-dessus du terrain de manière à fournir une vue aérienne.

raspivid permet d’afficher en direct ce que la caméra filme. Mais l’intérêt est faible dans notre cas : le direct, nous l’avons déjà sous les yeux.

Il est bien plus utile d’avoir un "direct" différé de quelques secondes : lors d’un but ou d’une action litigieuse, il suffit de tourner la tête pour revoir ce qu’il vient de se passer (à vitesse réelle).

Je me suis intéressé à faire fonctionner ce cas d’usage, dans le cadre de notre projet collectif babyfoot. Je vais détailler ici les principes et les problèmes rencontrés.

Un simple tube

La première idée fut de brancher le flux H.264 que produit raspivid sur l’entrée de omxplayer, qui serait démarré quelques secondes plus tard.

Premier problème, omxplayer ne semblait pas savoir lire sur son entrée standard. Ce n’est pas très gênant, il suffit d’utiliser un tube nommé grâce à mkfifo. En effet :

printf 'a\\nb\\nc\\n' | grep b

peut être remplacé par :

# terminal 1
mkfifo /tmp/fifo
printf 'a\\nb\\nc\\n' > /tmp/fifo

# terminal 2
< /tmp/fifo grep b

Mais en fait, il y a plus direct : omxplayer n’est qu’un script wrapper pour le vrai omxplayer.bin, c’est lui qui empêchait la lecture sur l’entrée standard. Il suffit juste d’exporter la variable qui-va-bien et d’appeler omxplayer.bin directement :

export LD_LIBRARY_PATH="/opt/vc/lib:/usr/lib/omxplayer"
omxplayer.bin …

Cependant, contrairement à ce que proposent beaucoup de commandes shell, omxplayer.bin ne prévoit pas explicitement de lire sur son entrée standard, il attend obligatoirement un fichier en paramètre. Donnons-lui donc comme fichier /dev/stdin !

raspivid -t 0 -w 1280 -h 720 -fps 25 -n -o - | omxplayer.bin /dev/stdin

Vu la durée de démarrage d’omxplayer.bin, pas besoin de retarder son lancement, la vidéo sera bien décalée de quelques secondes.

Le problème, c’est que le buffer lié au tube est très limité (man 7 pipe) : il sera très vite plein, bloquant totalement l’enregistrement et la lecture de la vidéo.

Avec un buffer

Nous avons besoin d’un buffer plus important. Pour cela, nous pouvons utiliser mbuffer, ici avec une taille de 10Mo :

raspivid … | mbuffer -m 10m | omxplayer.bin /dev/stdin

Et là, cela semble fonctionner.

Pour décaler un peu plus la lecture par omxplayer.bin, il est possible d’utiliser les commandes groupées (man bash) pour ajouter un appel à sleep avant le démarrage :

raspivid … | mbuffer -m 10m | { sleep 3; omxplayer.bin /dev/stdin; }

raspivid est censé enregistrer à 25 fps (-fps 25) et omxplayer nous indique dans la console qu’il lit à 25 fps.

Cependant, en réalité, le décalage n’est pas constant : il augmente petit à petit au fil des minutes, et le buffer se remplit légèrement plus vite qu’il ne se vide. La lecture consomme moins d’images que n’en produit l’enregistrement, comme si le débit d’images de l’enregistrement était supérieur à celui de lecture.

Il y a donc un manque d’exactitude (à ne pas confondre avec un manque de précision) dans le nombre d’images enregistrées et/ou lues par seconde.

Si nous tentons d’enregistrer à un débit légèrement inférieur (24 fps), c’est le contraire : le retard est rattrapé progressivement jusqu’à fournir une lecture en direct.

Comme le débit d’images est la seule information temporelle disponible et qu’elle est inexacte, il semble impossible de contrecarrer cette variation de délai.

Information temporelle

Mais en réalité, ce n’est pas la seule information temporelle dont nous disposons : nous savons que le flux est en direct.

Comment exploiter cette information ? Pour le comprendre, il suffit d’enregistrer à un débit d’images très faible (-fps 5) et de le lire toujours à 25 fps.

Si la lecture provient d’un fichier, alors la vidéo passe en accéléré. Par contre, si la lecture sort de la webcam en direct, alors la vidéo passe à vitesse normale mais à 5 fps : le lecteur a beau vouloir lire 25 images par seconde, s’il n’en reçoit que 5 chaque seconde, il n’a pas d’autre choix que de lire à 5 fps.

Ainsi, sans même connaître sa valeur réelle exacte, nous parvenons à obtenir le même débit d’images à l’enregistrement qu’à la lecture.

Mais comme nous l’avons vu, avec un débit d’images d’enregistrement inférieur, le délai introduit se réduira inexorablement (le retard sera rattrapé). Ce que nous voulons éviter : nous voulons un délai constant.

Delay

Nous avons cependant avancé, car maintenant, si nous disposions d’une commande qui retarde ce qui sort de raspivid pour le donner à omxplayer x secondes plus tard, et que nous enregistrons à un débit d’images légèrement inférieur à celui de la lecture, alors omxplayer rattrapera le retard pour parvenir au direct… décalé de x secondes. Exactement ce que nous voulons !

J’ai donc demandé sur stackoverflow si une telle commande existait, ce qui ne semblait pas être le cas.

Je l’ai donc implémentée (sous licence GPLv3) :

git clone http://git.rom1v.com/delay.git
cd delay
make && sudo make install

(ou sur github)

Elle permet de décaler tout ce qui arrive sur stdin d’un délai constant pour le sortir sur stdout :

delay [-b ] 

Elle est donc très générique, et n’a aucun lien avec le fait que le flux soit une vidéo.

Elle fonctionne aussi très bien pour différer la lecture de la webcam dans VLC sur un pc classique :

ffmpeg -an -s 320x240 -f video4linux2 -i /dev/video0 -f mpeg2video -b 1M - |
  delay 2s | vlc -

Nous pourrions penser qu’il suffit de faire la même chose avec raspivid et omxplayer, avec un débit d’images légèrement inférieur pour l’enregistrement (24 fps) :

raspivid -t 0 -w 1280 -h 720 -fps 24 -n -o - |
  delay -b10m 4s |
  omxplayer.bin /dev/stdin

Malheureusement, avec omxplayer, ce n’est pas si simple.

Initialisation immédiate

En effet, l’initialisation d’omxplayer pour une lecture vidéo est très longue (plusieurs secondes), et surtout, elle ne débute que lorsque une partie suffisamment importante de la vidéo à lire est reçue (les headers ne suffisent pas). Décaler la vidéo de x secondes décale également l’initialisation de x secondes, ajoutant d’autant plus de décalage.

Certes, le retard supplémentaire sera rattrapé progressivement, mais cela prendra du temps (environ 1 image chaque seconde, soit 1 seconde toutes les 25 secondes). Pour obtenir le délai désiré dès le départ, ce problème doit être évité.

Une solution de contournement consiste à passer les premiers (méga-)octets sortis de raspivid directement à omxplayer.bin, et de ne différer que le reste avec delay. De cette manière, les premières images seront lues immédiatement, permettant au lecteur de s’initialiser, alors que la suite sera différée.

Grâce aux commandes groupées de bash (encore elles), c’est très simple :

raspivid -t 0 -w 1280 -h 720 -fps 24 -n -o - |
  { head -c10M; delay -b10m 4s; } |
  omxplayer.bin /dev/stdin

La commande head va passer immédiatement les 10 premiers méga-octets à omxplayer.bin, puis la commande delay prendra le relai. Ainsi, l’initialisation aura déjà eu lieu quand les premiers octets sortiront de delay.

À part les premières secondes un peu chaotiques, le flux vidéo sera alors bien diffusé en différé avec un délai constant (testé sur 24 heures).

Conclusion

Nous avons donc bricolé une solution qui permet un replay différé en continu sur un Raspberry Pi

Original post of ®om.Votez pour ce billet sur Planet Libre.

Aujourd’hui, mon problème est du côté de ma base de données MySQL : j’ai inséré une grande quantité de lignes et je crois que j’ai des doublons dans une de mes tables. Comment vais-je vivre avec cela ? Je m’y refuse. Ma bataille du jour : me débarrasser de ces doublons mais tout en gardant au moins une ligne dans le cas des doublons.

MySQL : Lister tous les doublons

La requête suivante permet de récupérer toutes les lignes groupés par un champ identique ayant plus d’une ligne.

SELECT COUNT(field), field
FROM table
GROUP BY field
HAVING COUNT(field) > 1

Mais si j’ai plus d’un champ à regrouper ? Alors on l’ajoute au

GROUP BY

.

SELECT COUNT(field1), field1, field2
FROM table
GROUP BY field1, field2
HAVING COUNT(field1) > 1

MySQL : Supprimer ces doublons

Technique #1 : Utilisation de LEFT OUTER JOIN

Maintenant que l’on a récupéré nos doublons, il faut les supprimer.

Que se passe-t-il si on exécute cette requête ?

DELETE FROM table
GROUP BY field
HAVING COUNT(field) > 1

Résultat : Tous les doublons sont supprimés mais il ne reste plus aucune exemplaire de la ligne.

Comment supprimer les doublons et n’en garder qu’un exemplaire ?

• Tout d’abord, on va récupérer la clé primaire la plus petite de chaque groupe de doublons de façon à le garder et effacer les autres
• Ensuite, on va lier cette sous-requête à notre table principale par la clé primaire pour ne garder que les lignes qui ont soit aucun doublon, soit quand ils ont un doublon, la ligne avec la clé primaire la plus petite.
• Donc les lignes qui ne seront pas liés seront les lignes à supprimer, les lignes en doublon.

DELETE table 
FROM table
LEFT OUTER JOIN (
        SELECT MIN(id) as id, field1, field2
        FROM table
        GROUP BY field1, field2
    ) AS table_1 
    ON table.id = table_1.id
WHERE table_1.id IS NULL

Technique #2 : Utilisation d’un index UNIQUE

La technique est d’ajouter un INDEX sur la table sur les champs qui ne doivent pas être dédoublonnés. Automatiquement, les doublons seront supprimés.

ALTER IGNORE TABLE table 
  ADD UNIQUE INDEX(field1, field2);

Lien : http://souptonuts.sourceforge.net/readme_mysql.htm

[EDIT 2014-01-24 20:30] FIXED : Erreur dans la requête SQL de suppression des doublons
[EDIT 2014-01-24 20:40] ADDED : Ajout d’une technique grâce à @Biapy

Cet article MySQL : Comment nettoyer une table de ces doublons ? est apparu en premier sur RootsLabs.

Original post of Progi1984.Votez pour ce billet sur Planet Libre.

Si vous disposez d’un PC portable vous le savez sans doute, l’autonomie est une priorité et pour ainsi dire, le nerf de la guerre. Il y a pas mal de moyens à mettre en œuvre pour réduire la consommation en ressources de nos machines et augmenter ainsi leur autonomie, à commencer par la luminosité qui n’a pas toujours besoin d’être au taquet. Disposer d’un outil nous permettant d’ajuster automatiquement la luminosité de nos écrans en fonction de la lumière ambiante peut être intéressant et ça tombe bien, car c’est exactement ce que propose WildGuppy. Celui-ci va pouvoir réaliser cet exploit en analysant à intervalles réguliers, les images captées par les webcams intégrées à nos PC. C’est en quelque sorte le même principe que celui utilisé par les capteurs de nos Smartphones. Si ça vous branche nous allons voir de suite comment en profiter sur Ubuntu et dérivés.

Installer WildGuppy sur Ubuntu et dérivés :

La première chose à faire (ne riez pas) est de vérifier que votre machine possède bien une webcam intégrée. Si c’est le cas il va falloir que vous installiez les paquets Xbacklight et Fswebcam, qui seront nécessaires pour que le programme fonctionne.

sudo apt-get install xbacklight fswebcam

Une fois que c’est fait téléchargez cette archive Deb et installez le paquet en utilisant Synaptic, gdebi ou l’USC.

Pour finir téléchargez l’utilitaire de configuration et ajoutez le à la liste de démarrage des programmes à l’aide des commandes suivantes :

Téléchargement :

wget http://dl.dropboxusercontent.com/s/bcnzhxv6mrmipdd/wildguppy-gtk.desktop -O

Configuration :

~/.config/autostart/wildguppy-gtk.desktop

Vous pouvez maintenant lancer WildGuppy en passant par le menu des applications, comme vous le feriez pour d’autres programmes. Sous Gnome l’indicateur (un petit poisson) va apparaître dans la barre de notifications et non dans le panel supérieur comme sur Unity par exemple :

Cet indicateur va vous permettre de faire apparaître un menu déroulant depuis lequel vous pourrez entre autres, démarrer, stopper ou relancer le programme, choisir manuellement le niveau de luminosité, ou quitter complètement l’application.

Vous pourrez également accéder au menu « Settings », qui va vous permettre de choisir la fréquence de rafraîchissement et la luminosité mini/maxi à tolérer.

A partir de là WildGuppy va analyser régulièrement les images captées par votre webcam et adapter la luminosité de votre écran en fonction de ces dernières et de la luminosité ambiante. C’est très sympa et super bien pensé. Reste à voir si c’est réellement efficace en terme d’autonomie, mais pour cela il faut prendre le temps de le tester en situation réelle, ce que je n’ai pas encore pu faire.

Si vous voulez en savoir plus sur ce projet, vous pouvez jeter un œil sur cette page.

Amusez-vous bien.

source

Original post of La vache libre.Votez pour ce billet sur Planet Libre.