Contenu | Rechercher | Menus

Annonce

Si vous rencontrez des soucis à rester connecté sur le forum (ou si vous avez perdu votre mot de passe) déconnectez-vous et reconnectez-vous depuis cette page, en cochant la case "Me connecter automatiquement lors de mes prochaines visites". Attention, le forum rencontre actuellement quelques difficultés. En cas d'erreur 502, il ne faut pas re-valider l'envoi d'un message ou l'ouverture d'une discussion, au risque de créer un doublon.

La section divers se réorganise ! De nouvelles sous-sections à venir. (plus d'infos + donner son avis)

nombre réponses : 25

#0 -1 »  Clé USB morte ? Vue par le noyau, pas pas udev » Le 06/04/2012, à 20:29

Laserpithium
Réponses : 4

Bonjour à tous,

Ma soeur a crashé une clé USB en l'arrachant sauvagement sans la démonter proprement auparavant.
Depuis, elle n'est plus reconnu par le système (la clé, pas ma soeur). Pire: la diode clignotante ne s'allume plus...
Brèf, ça sent à plein nez la panne matérielle, mais j'aimerais voir si je peux tenter un truc ou deux avant de la déclarer (avec ses données) perdue.

En particulier, ce qui m'intrigue, c'est que linux semble la détecter. Lorsque je branche la clé:

$ dmesg
 [ 3750.213056] usb 2-2: new high-speed USB device number 5 using ehci_hcd

Par contre udev ne semble rien reconnaitre: un ls /dev ne montre aucun nouveau périphérique.
Du coup, n'ayant même pas de sdX à essayer de mounter ou autre, je suis un peu sec...

Quelqu'un aurait-il une idée ?

Bonne soirée,

Laserpithium

#1 Re : -1 »  Clé USB morte ? Vue par le noyau, pas pas udev » Le 07/04/2012, à 10:42

Laserpithium
Réponses : 4

Merci pour le coup de main!

Faire un fsck était mon idée initiale, mais le problème c'est que le périphérique n'apparaît pas dans la liste des périphériques...
Un  fdisk -l par exemple ne fait rien apparaître après avoir branché la clé. Ni partition (sdc1 par exemple), ni même table de partition (sdc).
Du coup, je sèche...

#2 Re : -1 »  Pas de dual boot Linux avec Windows 8 en présence d’un CPU ARM » Le 22/01/2012, à 12:27

Laserpithium
Réponses : 15

C'est une approche de type "quitte ou double".

J'ai lu ça quelque  part (je n'ai plus la source, désolé), mais l'article disait qu'aujourd'hui moins de 50% des "ordinateurs" vendus l'étaient sous leur forme "classique" (tour ou portable). Plus de 50% sont des tablets ou des smartphones.
Hors Microsoft, depuis 25ans, tout ce qu'ils savent faire c'est vendre du Windows et de l'Office pour PC "classique" (avec un petit succès avec la XBox). Donc aujourd'hui, incapables comme toujours de s'adapter, ils voient le troupeau de vache qu'ils traient proprement depuis 25 ans s'amenuiser peu à peu. D'où problème.
Comme ils sont incapables d'innover technologiquement, ils résolvent ce problème de leur manière habituelle: par abus de position dominante. "Messieurs les assembleurs d'ARM, soit vous êtes uniquement pour nous, soit vous êtes contre nous". Et ils vont tenter ainsi de remettre la main sur les 50% du troupeau qui se barraient ailleurs en empêchant les leaders "naturels" du marché ARM (Android, Linux etc) d'y avoir tout simplement accès.
Etant donnée leur situation, c'est parfaitement sensé. Mais c'est aussi absolument dégueulasse, c'est pour ça qu'il existe (normalement) des législateurs pour empêcher cela. En espérant que ces derniers vont faire quelque chose.

#3 -1 »  [Résolu] Problème développement Plasmoide » Le 05/02/2012, à 10:35

Laserpithium
Réponses : 2

Bonjour à tous,

Je suis en train de développer un plasmoid en C++ sous KDE 4.8.
Le plasmoid fonctionne bien, et j'ai alors décidé d'ajouter une petite page pour la configuration (accessible en cliquant sur la petite clé à molette standard à côté du plasmoid lorsque les éléments du bureau sont libérés).
Cependant, lorsque je lance alors le plasmoid pour test avec la commande:

plasmoidviewer -c rgbPlasma

J'obtiens l'erreur suivante, que je ne sais pas interpréter:

plasmoidviewer(2386)/libplasma Plasma::AppletPrivate::mainConfigGroup: requesting config for "rgbPlasma" without a containment!

Quelqu'un sait-il de quel type d'erreur il s'agit ? Et si oui,  comment le résoudre ?

Merci.

#4 Re : -1 »  [Résolu] Problème développement Plasmoide » Le 05/02/2012, à 16:01

Laserpithium
Réponses : 2

Effectivement, ça résout mon souci !

Merci à toi.

#5 -1 »  $PATH dans la console Dolphin ? » Le 08/01/2012, à 20:57

Laserpithium
Réponses : 5

Bonjour,

Dolphin permet, en appuyant par défaut sur F4, d'avoir un terminal qui s'affiche dans le bas de la fenêtre de Dolphin, ce qui est, je trouve, extrêmement pratique.
Cependant, j'ai modifié le $PATH de mon installation pour pointer sur des répertoires contenant mes scripts perso, et la console intégrée à Dolphin ne semble pas le voir.

Un echo $PATH dans Konsole me lit bien le $PATH modifié, et mes scripts sont bien reconnus.
Mais un echo $PATH dans la console intégrée à Dolphin ne liste que les répertoires par défaut, et bien évidemment mes scripts ne marchent donc pas (à moins d'aller les chercher "à la main" dans leur dossier bien entendu, ce qui est très pénible).
Est-ce que quelqu'un sait où paramétrer le $PATH utilisé par le terminal intégré à Dolphin ?

Merci pour votre aide
(Au fait, je suis sur KDE SC 4.7).

#6 Re : -1 »  $PATH dans la console Dolphin ? » Le 08/01/2012, à 21:35

Laserpithium
Réponses : 5

Merci pour ta réponse.

Effectivement, j'ai modifié mon $PATH dans mon $HOME/.bashrc
Et donc quand je fais un source $HOME/.bashrc, ça marche, je récupère donc bien mon $PATH modifié dans Dolphin.
Cependant, comment faire pour que ce comportement soit celui "par défaut" lors de l'ouverture de Dolphin ? (cad que je n'ai pas à lui demander manuellement de sourcer)
Faut-il que je place mon $PATH modifié ailleurs que dans mon .bashrc utilisateur ? (du genre dans /etc/bash.bashrc, mais c'est peut-être un peu violent non ?)
J'ai essayé de regarder le dolphinrc, mais je n'ai rien trouvé de bien concluant dedans pour lui dire de chercher le bon fichier à sourcer à l'ouverture...

Il est un peu bête Dolphin sur ce coup là, parce qu'en plus du traditionnel Konsole j'utilise aussi Yuakake (le terminal déroulant "à la Quake"), qui lui me source bien tout comme un grand.

#7 Re : -1 »  $PATH dans la console Dolphin ? » Le 09/01/2012, à 20:35

Laserpithium
Réponses : 5
[gilgamesh@Uruk ~]$ cat .bash_profile 
. $HOME/.bashrc

J'en déduis que l'appel de bash_profile revient à appeler le bashrc, donc je ne pense pas que ça soit cela.

#8 -1 »  [Electricité] Câblage d'un transformateur » Le 27/12/2011, à 15:31

Laserpithium
Réponses : 14

Bonjour à tous,

Question qui n'a rien à voir avec Ubuntu, mais le geek étant bidouilleur à ses heures, je me dis que poster ici peut être justifié !

Je me suis bidouillé un contrôleur de LED RGB, et envisage de profiter de la réfection prochaine de mon appart pour installer des bandeaux leds un peu partout (des blancs sur une corniche en dessous du plafond pour de l'éclairage indirect, et quelques RGB pour faire fun).

Je vais donc installer 4 bandeaux leds, 12V, ces 4 bandeaux devant être parfaitement indépendants.

Concernant le câblage, je suis libre de faire ce que je veux. Et ayant l'embarras du choix, je me pose la question suivante: dois-je obligatoirement installer les interrupteurs commandant les bandeaux en amont du primaire des transfo 12 V (sur le 220V donc) ? En effet:

- Option 1, "classique": 220V tableau -> 4 interrupteurs en parallèle -> 4 transformateurs 12V -> 4 bandeaux LED
Donc qui dit 4 bandeaux leds indépendants commandés par 4 interrupteurs différents dit 4 transformateurs...

- Option 2, "alternative": 220V tableau -> 1 unique transfo 12V commun aux 4 bandeaux -> 4 interrupteurs en parallèle -> 4 bandeaux LED
Dans cette solution, un transfo 12V est en amont de l'installation et je me crée un bus 12V, sur lequel viennent se raccorder les bandeaux LED via un inter.

Avantage solution 2: 1 seul gros transfo de 300W au lieu de 4 moyens et petits, donc économie de 60€.
Inconvénient solution 2: le primaire du transfo reste sous-tension en permanence. Impact sur la durée de vie, sur l'échauffement ? De plus, cela signifie dans ce scénario que le transfo fonctionnera loin de son nominal (le cas où tous les bandeaux sont allumés en même temps est rare, le transfo opèrera 80% du temps sans charge et les 20% restant à 30% de charge environ pratiquement tout le temps).

Qu'en pensez-vous ? La solution 2 (permet de diviser par 2 la facture en transfo) est-elle jouable ou est-ce franchement déconseillé ?
Question subsidiaire: récupérer une veille alim de PC est-ce une bonne idée, ou bien les différents connecteurs devant être reliés à la carte mère (alim OK, carte OK etc) posent-ils trop de souci ?

#9 Re : -1 »  [Electricité] Câblage d'un transformateur » Le 27/12/2011, à 21:49

Laserpithium
Réponses : 14

Bonjour à tous,

1) Merci pour vos nombreuses réponses !

2) Quelques précisions:
- Je parle de "transformateur 12V", mais c'est un abus de langage. Il s'agit en fait d'alimentation stabilisée (à découpage modulaire).
- Concernant les bandeaux led, on en trouve un peu partout, exemple: http://www.espaceampoules.fr/bandeau-le … -jour.html
Je vais fabriquer une corniche de 20cm de large fixée le long du mur environ 20cm sous le plafond, et sur laquelle je vais déposer des bandes LED (qui éclairent le plafond blanc en éclairage indirect). Il y aura des bandes LED blanches (blanc solaire) pour l'éclairage "normal", et je vais installer aussi un ruban RGB pour générer des couleurs à volonté, ce qui peut être sympa à bidouiller !
J'ai monté un kit de contrôle de bandeau RGB trouvé ici:  http://picprojects.org.uk/projects/bigm … /index.htm. J'ai adapté le logiciel du microcontroleur téléchargé sur le site à mon besoin (l'assembleur PIC, c'est l'horreur) et programmé une application en C pour communiquer avec le controleur led via une interface série (le tout basée sur une appli client/serveur: le controleur led est connecté à un serveur basse conso qui tourne en permanence (et fera aussi serveur mail, de fichiers etc), et la partie client tourne sur n'importe quel autre PC (linux :-)) qui communique via ethernet avec le serveur pour envoyer les commandes). C'est marrant à réaliser et permet de réaliser plein de choses sympas:
- Eclairage auto le matin pour se réveiller, en simulant l'aube
- "Ambi-light" à la Philips
- Asservissement à Amarok pour faire effet discothèque :-)
J'envisage à terme de releaser tout ça sous GPL, mais j'ai appris la prog "sur le tas" et je suis conscient de la faible qualité de mon code (même si il produit le résultat escompté), et ça m'embête donc de mettre ça publique.

J'attaque les travaux début janvier, j'espère avoir terminé mi février (je refais la cuisine et le salon). Je posterai quelques photos du rendu final.

#10 Re : -1 »  [Electricité] Câblage d'un transformateur » Le 29/12/2011, à 17:03

Laserpithium
Réponses : 14
xenusis a écrit :

bonjour  je me permet une précision quand a le section des fils utiliser,   la tension en fin de ligne sera plus faible (problème du continu)  donc bien calculer cela ,même si les diodes sont de faible consommatrice , il y aura a voir les écrit,  une quantité importante !!!

Prévu, je prends une alim avec tension de sortie ajustable.
Je règle à 12,0V sans charge, je branche la charge (bandeau led allumé), et je remonte la tension de sortie de l'alim jusqu'à avoir 12,0V aux connections avec le bandeau.

#11 Re : -1 »  [Electricité] Câblage d'un transformateur » Le 29/12/2011, à 18:23

Laserpithium
Réponses : 14
xenusis a écrit :

13,2 volt serai mieux   en charge !!!

Pourquoi ? La spec du bandeau led précise 12V, donc je pensais ajuster à 12V en charge aux bornes du bandeau... Pourquoi 13.2V ?

#12 -1 »  Domotique, X10 et CPL Freebox » Le 28/11/2011, à 16:58

Laserpithium
Réponses : 0

Bonjour les amis,

Sujet un peu technique.
Je pense m'offrir pour les fêtes de fin d'année de quoi me bricoler un petit serveur perso, dédié en partie (mais pas uniquement) à de la domotique.
Je zone donc un peu sur le web, afin de valider une solution technique. D'où ma question:
Mon FAI est Free, et ma freebox server et la freebox TV sont reliées entre elles par CPL (courant porteur). Cela risque-t'il de créer des interférences avec des modules utilisant le protocole X10, qui utilise lui aussi le CPL ?
Puis-je utiliser la technologie X10 dans une telle situation ?

#13 Re : -1 »  Ou vous fournissez vous? » Le 11/11/2011, à 19:41

Laserpithium
Réponses : 26

Pour les habitants de Paris et environs, je recommande vivement Selectronics, métro Nation (à l'angle de la place).

#14 Re : -1 »  Combien de douches ? (topic alacon) » Le 07/10/2011, à 12:19

Laserpithium
Réponses : 347

1 douche par jour, le soir avant de me coucher.
ça ne me gêne pas de me sentir un peu crade en journée (par exemple un jour où il fait chaud et où on transpire pas mal dans le RER), mais je suis incapable de me mettre dans mon lit en me sentant sale.
Donc c'est douche tous les soirs.

Le souci, c'est que j'avoue que j'ADORE prendre des douches. Je reconnais, c'est pas génial pour la planète, mais c'est mon péché mignon, je pourrais rester 1h sous un jet d'eau chaude bien fort bien chaud.
Je me réfrène quand même, donc en général c'est 10 minutes par douche. Mais j'en prend parfois le WE une en journée, juste pour le plaisir.

#15 Re : -1 »  Combien de douches ? (topic alacon) » Le 07/10/2011, à 13:10

Laserpithium
Réponses : 347
helly a écrit :

c'est pas génial pour la planète

Discourt d’écolo ça ! tongue
La planète elle s’en fout que tu prennes une douche ou que tu conduises un 4×4, c’est pas ça qui va la faire exploser ^^.
Non, il faudrait plutôt dire un truc genre « c’est pas cool pour les reserves d’eau » ou un truc dans le genre. wink

Effectivement.
Je reformule donc: ce n'est pas génial pour un grand nombre d'espèces végétales et animales, ainsi que pour la civilisation telle que nous la connaissons.

#16 Re : -1 »  [résolu] Changement d'architecture, réinstallation obligatoire ? » Le 13/08/2011, à 11:48

Laserpithium
Réponses : 5

L'architecture "de base" reste la même (x86_64), donc pas besoin de réinstaller.
Exception: si tu as compilé par toi-même certaines sources en paramétrant gcc pour compiler en fonction des particularités propres de ta famille de processeur. A ce moment là, il faudra recompiler ces programmes spécifiques.

#17 Re : -1 »  Pétrole : le torchage, une aberration à donner envie de hurler » Le 30/06/2011, à 21:29

Laserpithium
Réponses : 56

C'est un peu plus compliqué que ça.
On ne torche pas les gaz uniquement pour le plaisir de polluer ou parce que l'on n'a pas envie de s'emmerder.

Ce qui remonte du puit, ce n'est pas du "pur" méthane, c'est un mélange contenant:
- Du méthane en grande partie
- De l'azote
- De l'eau
- D'autres hydrocarbures (ethane, propane, un peu de butane)
- Des saloperies type H2S, Mercure etc
- Parfois de l'hélium suivant les puits
Brèf, ça coûte très cher à purifier (sans compter qu'ensuite il faut le liquéfier pour le transporter, ce qui a un coût (investissement + énergie) important).
Et récupérer la chaleur issue de la torche n'est pas évident non plus, car les gaz de combustion sont corrosifs (ça boufferait les chaudières rapidement).

Donc oui on pourrait le récupérer si on s'en donnait les moyens, oui ça fait mal de bruler ça à l'heure actuelle où les ressources apparaissent comme limitées et l'environnement doit être respecté, mais ce n'est pas aussi simple que ça.

#18 Re : -1 »  Une petite question philisophique concernant la défragmentation... » Le 04/07/2011, à 13:19

Laserpithium
Réponses : 12

C'est non seulement inutile mais de plus très déconseillé de défragmenter un ssd:
- la fragmentation, cela signifie qu'un fichier est stocké en plusieurs petits morceaux répartis un peu partout sur le disque, au lieu d'un seul bloc contigu de données. Sur un disque dur classique, cela ralenti l'accès à l'information (le disque se met en position pour lire le premier segment, le lit, puis perd du temps pour chercher le deuxième, le lit, puis perd du temps à chercher le troisième etc). Sur un SSD, où l'info est stockée dans une puce de mémoire flash, cela ne coûte pas plus cher d’accéder à une zone donnée ou à plusieurs zones. Donc si un SSD est fragmenté, cela n'a aucune incidence sur le fonctionnement du système.
- Par contre, autant un disque dur classique peut supporter un nombre de cycles lecture/écriture extrêmement important avant de lâcher, ce n'est pas le cas des SSD: chaque zone mémoire ne supporte en effet que quelques milliers de cycles d'écriture.
Donc si tu défragmentes ton SSD, tu vas procéder "pour rien" (cf point 1) à un grand nombre d'écritures, et tu vas in fine réduire la durée de vie de ton disque sans aucun avantage en échange.

Donc il est non seulement inutile de défragmenter un SSD (même complètement fragmenté), mais en plus dangereux pour le SSD en question.

#19 -1 »  [Résolu] C++: envoyer des commandes à intervalle de temps divers » Le 01/07/2011, à 14:48

Laserpithium
Réponses : 10

Bonjour,

J'ai créé un petit programme en C/C++ permettant d'envoyer des données sur le port série pour commander un contrôleur de led RGB.
En gros: j'appuie sur le bouton "Rouge" et les leds s'allument en rouge.

Je souhaite à présent aller un peu plus loin, et programmer des actions automatiques (par exemple, effets stroboscopiques): Chaque x secondes, le programme choisit une nouvelle couleur et l'envoie tout seul comme un grand sur le port série.
Ce que je ne sais pas faire, c'est ce "attend x secondes": je peux le faire via une sale boucle while, mais ça me fait mal d'avoir le proco à 100%.
Utiliser la fonction sleep pourrait marcher, mais cela implique de passer par un thread si je veux garder mon interface graphique active n'est-ce pas ? Je ne connais pas trop les threads et je ne vois donc pas si cela me permet de faire ce que je veux.

Idéalement, il faudrait construite cela de le manière suivante:
- Le programme principal (qui fait tourner l'interface graphique typiquement) envoie des commandes toutes les x secondes (x par forcément constant).
- Un programme secondaire est "éveillé" lors de l'émission de ce signal, il envoie la commande aux LED puis se remet en sommeil.
Comment faire pour que le programme principal émette ce signal ponctuellement, sans avoir une sale boucle while qui tourne pour incrémenter une variable servant de timer ?

#20 Re : -1 »  [Résolu] C++: envoyer des commandes à intervalle de temps divers » Le 01/07/2011, à 18:36

Laserpithium
Réponses : 10
omc a écrit :

Bonjour,
Tu utilises quel lib pour l'interface graphique ?

Qt (KDE power cool)

Mais la partie communication client/serveur et la communication avec le port série est faite en C.

#21 Re : -1 »  [Résolu] C++: envoyer des commandes à intervalle de temps divers » Le 02/07/2011, à 17:17

Laserpithium
Réponses : 10
claudius01 a écrit :

Bonjour,
La fonction alarm devrait répondre à ton problème et pas besoin d'un second process
cf. man alarm

Essayé avec alarm(), ça marche nickel, exactement ce que je cherchais, merci !

Une question cependant:
- J'ai alarm() qui prend en paramètre un nombre entier de secondes (testé et fonctionne)
- J'ai ualarm() qui prend en paramètre un nombre entier de microsecondes (testé et fonctionne)
Donc actuellement je sais attendre entre deux commandes un nombre entier de seconde, mais ualarm() ne fonctionne pas chez moi si je passe en paramètre plus de 1 million de microsecondes.

Donc comment est-ce que je peux faire pour attendre par exemple 1.3 secondes ?

#22 Re : -1 »  [Résolu] C++: envoyer des commandes à intervalle de temps divers » Le 02/07/2011, à 18:12

Laserpithium
Réponses : 10
grim7reaper a écrit :
Laserpithium a écrit :

ualarm() ne fonctionne pas chez moi si je passe en paramètre plus de 1 million de microsecondes.

Y'a pas que chez toi hein, c'est normal.

man 3 ualarm a écrit :

The  type useconds_t is an unsigned integer type capable of holding integers in the range [0,1000000].

OK, du coup de fait quoi ?

ça voudrait dire que je peux additionner les délais en appelant à la suite alarm() et ualarm() ?

#23 Re : -1 »  [Résolu] C++: envoyer des commandes à intervalle de temps divers » Le 02/07/2011, à 21:35

Laserpithium
Réponses : 10

Génial, ça marche !

Merci à tous

#24 -1 »  Logiciel/Plugin pour extraire bpm d'une musique lue par Amarok » Le 02/07/2011, à 19:49

Laserpithium
Réponses : 0

Bonjour à tous,

J'ai créé un petit soft pour contrôler via mon PC des led RGB.
J'arrive à faire clignoter mes LEDs pour générer des couleurs de manière aléatoire, mais je dois entrer manuellement la fréquence à laquelle les couleurs doivent changer.

Ce que j'aimerais à présent, c'est pouvoir coupler cela avec amarok: lors de la lecture d'une piste par Amarok, pourvoir récupérer les bpm de la piste en cours et utiliser ce paramètre pour driver mes leds (et faire donc varier les couleurs en fonction de la musique).
J'ai regardé la liste des scripts amarok permettant de réaliser cela, mais je n'ai rien trouvé (mis à part un vieux plugin qui fait cela... mais pour winamp).

Quelqu'un aurait-il une piste ?