votre avatar Abonné

millman42

est avec nous depuis le 11 avril 2013 ❤️

575 commentaires

Le 25/09/2014 à 12h 24







levhieu a écrit :



Or donc, on peut passer des variables d’environnement par d’autres moyens, propres à chaque daemon concerné. Mais pour reprendre l’exemple de ssh, quand j’ouvre une session en passant des variables d’environnement, le sshd se contente de les placer dans l’environnement du processus utilisateur créé. Ou alors, c’est sur sshd qu’il faut se pencher (pas forcément inutile d’ailleurs, au vu de ce qu’on a appris depuis le début de l’année).





Oui en effet je me suis trompé.


Le 25/09/2014 à 12h 12







loloemr a écrit :



Bah non.





Saut que le serveur ssh est lancé en root et que la commande est donc lancé par l’utilisateur root.



Edit : en effet j’ai dis des bêtises cela permet uniquement de contourner les restrictions d’accès à une seule commande utilisé par exemple par gitolite.


Le 25/09/2014 à 12h 07







obrowny a écrit :



c’est beau de voir dans la même news qu’une faille a été découverte et deux lignes plus loin qu’elle a été patchée. Ça souligne une belle réactivité de l’écosystème quand même !





Sauf que le patch ne corrige pas entièrement la faille.


Le 25/09/2014 à 12h 06







loloemr a écrit :



Encore faudrait-il avoir le mot de passe ou la clé pour se connecter en SSH.





Cela permet tout de même à quelqu’un  possédant un compte user d’exécuter une commande root. J’appelle ça une élévation de privilège moi.


Le 25/09/2014 à 11h 55







levhieu a écrit :



Utilise une erreur à l’intersection entre le traitement par bash de l’initialisation de l’environnement et de la définition des fonctions pour exécuter des commandes d’une manière inhabituelle.



À mon tour maintenant de demander en quoi c’est une faille si importante:




  • Pas d’élévation de privilège

  • Pour exécuter la commande dite dangereuse, faut déjà avoir le droit d’éxécuter n’importe quelle commande. Alors ?





    Pas d’élévation de privilège je ne suis pas d’accord si on l’utilise sur un serveur ssh on peut exécuter des commande en root, de même que lorsqu’on l’utilise avec dhcpclient (car ces deamon sont exécuter en root). Et pour exécuter la commande dangereuse il faut juste pouvoir exporter une variable d’environnement. Ce que fais apache avec le mod cgi ou dhcpclient …


Le 25/09/2014 à 12h 10







Inny a écrit :



Marrant, j’ai vu des études démontrant le contraire. Mais ça, ça n’est pas dans l’intérêt des copains cigarettiers. <img data-src=" />





En effet c’est surtout une porte de sortie.


Le 24/09/2014 à 13h 51







larkhon a écrit :



J’imagine que le Royaume-Uni ayant trouvé cette merveilleuse idée, on s’empresse de les appliquer chez nous, sans prendre de recul.



Je vois pas l’intérêt d’apprendre du code, y a un pays entier de développeurs, ça s’appelle l’Inde. Quand on voit que les entreprises achètent de plus en plus d’offshore même pour des tâches très qualifiées, on arrive sans doute 15-20 ans trop tard avec cette idée, et on peut se demander à quoi ça va servir.



En revanche, apprendre la recherche d’information, la sécurité, la distinction public/privé, ça ce sont des choses à mettre en avant. Au collègue, la gestion de projet (informatique) peut être intéressante pour la démarche, des algorithmes pour la technique.





En Inde faut se méfier en générale il mette des débutants en face avec un turn over énorme se qui fait que en un mois on peut facilement changer trois quatre fois de développeurs et faut tout réexpliquer à chaque fois pour au finale refaire soit même tout le développement.


Le 23/09/2014 à 12h 47







Anachron a écrit :



Si c’est juste un client qui gère mieux l’upload que tu cherches, tu peux installer Transmission à la place de Download Station aussi.



Je n’ai jamais essayé mais il ne devrait pas y avoir de soucis pour envoyer tes propres torrents avec.&nbsp;







Download Station de Synology repose sur Transmission pour la partie torrent.


Le 21/09/2014 à 18h 06







seboquoi a écrit :



Donc tout repose toujours sur le code à 4 chiffres?







Oui après j’imagine qu’il est “salé” avec un des identifiants unique du produit stocké dans une OTP (qui normalement ne doit accessible que si tu toutes la chaîne de confiance a été validé).



Par contre s’ils fond ça le veut dire que si le bootloader est déverrouillé le chiffrement peut être cassé facilement (avec attaque bruteforce sur un code à 4 chiffres).


Le 19/09/2014 à 15h 28







seboquoi a écrit :



Petite question, vous dites qu’on ne pourra pas y accéder faute d’avoir une puissance titanesque. Mais matériellement cela signifie quoi, que faute d’avoir le code à 4 chiffres que je tape pour déverrouiller le téléphone son contenu sera crypté?







En faite le code à 4 chiffres sert à déchiffrer la clé de déchiffrement des données. Donc si tu changer de code il suffit de chiffrer la clé avec ce nouveau code.


Le 19/09/2014 à 15h 13







LordZurp a écrit :



j’avais testé mon vénérable galaxy S (le premier, le meilleur :) ) et, c’est logique, ça faisait ramer l’os à mooooooort …



à quand une prise en charge d’AES par Arm en natif ? comme chez intel depuis sandy bridge (i5)







C’est déjà le cas sur pas mal de SoC.


Le 18/09/2014 à 12h 45







Nilav a écrit :



Même question que Faith, si je comprends bien, on leur a carrément vendu l’usage de l’extension ? Par exemple, personne d’autre qu’Amazon va pouvoir utiliser un .buy ?



Si oui, c’est un peu spécial.







Si Amazon pourra revendre dans domaine en .buy après. Mais l’avantage c’est qu’il a la priorité.


Le 17/09/2014 à 15h 42







Jarodd a écrit :



Il est en paquet à installer soi-même, ce n’est pas un hébergeur au sens où on l’entend. Ou alors j’ai pas compris la remarque <img data-src=" />







Moi je voudrais bien pouvoir utiliser cloud sync de Synology avec mon serveur Owncloud sur mon serveur.



C’est cela le sens de ma remarque.


Le 17/09/2014 à 15h 10







NewLook a écrit :



Arf…. il manque toujours MEGA comme hébergeur <img data-src=" />







Et owncloud.


Le 12/09/2014 à 12h 27







HarmattanBlow a écrit :



Ça a un autre avantage, tout simple : tu n’as pas à maintenir un tas en mémoire et sur le disque.



Ce type de structure est nécessaire si tu veux éviter la fragmentation. NTFS n’en n’a pas besoin.





Cette optimisation est négligeable, on parle de trois poils de mouche, à quoi bon concentrer des efforts là-dessus et pourrir le code ?



Ensuite j’adore ta formulation : “futé”. On croirait que ce sont des abrutis qui ne connaissent pas les super-astuces du monde Linux, ça me fait marrer. Pas du tout ridicule.



Tu sais pourquoi il y a tant de petites astuces dans le monde Linux ? Parce que les dévs préfèrent se palucher avec ces petites astuces plutôt que de contribuer à des choses vraiment utiles. Je sais de quoi je parle, je suis dév.





C’est à ça que sert la défragmentation : elle repousse le paiement de la taxe d’écriture aux temps morts plutôt que de la payer lors de l’écriture elle-même. Si bien que tu finis avec des écritures rapides ET des lectures rapides.







NTFS tien un journal comme ext4 pour éviter la fragmentation. cf wikipadia


Le 11/09/2014 à 08h 16







Tourner.lapache a écrit :



Qu’est-ce que ça vaut un Windows Storage Server 2012 R2 face à un Freenas par exemple ? Ca supporte le ZFS ?







Non cela ne supporte pas ZFS. Les avantages sont cités dans la news, c’est l’intégration avec office 360 et les services de cloud de microsoft. CoooolRaoul rajoute que cela apporte une meilleur indexation.


Le 09/09/2014 à 16h 06







blamort a écrit :



Quel est l’avantage de Plex par rapport a XBMC sur une tablette qui aurait acces au NAS/mediacenter ?







Aucun, pour moi le couple xbmc/yatse est le meilleur. Finalement avec cela je n’utilise quasiment plus mon chromecast.


Le 05/09/2014 à 08h 13







Ler van keeg a écrit :



Le seul service de cloud dans lequel je mets un minimum de confiance, c’est mon Owncloud hébergé sur un serveur dédié, et encore je n’y mets que des trucs qui peuvent me servir quand je suis loin (musique, quelques vidéos, fichiers sur lesquels je bosse) mais le stockage sur le cloud, non.







Même chose.


Le 28/08/2014 à 14h 00







OlivierJ a écrit :



Qu’est donc yast ? Pour moi “yast” c’est l’installeur de la distribution SuSE.







On effet je me suis trompé de nom c’est yatse. Une application Android de télécommande pour XBMC.


Le 28/08/2014 à 13h 36







mononokehime a écrit :



Ce qui me dérange le plus c’est de ne pas avoir d’infrarouge intégré, surtout pour XBMC, car de toute façon le dock disque dur sera a coté pour les données importantes et les films de vacance.







Mais je ne plus avoir de port infrarouge ne me gêne plus pour XBMC depuis que j’ai découvert yast. Sinon en général les NUC de Zotac supporte l’HDMI CEC.


Le 21/08/2014 à 16h 01







atomusk a écrit :



C’est encore pas mal utilisé dans l’industrie le port serie … un port simple à programmer et débugger, peu cher à intégrer …







Oui en faite leur PC fait plus penser à un système industriel notamment à cause du port série et SoC qui est plus orienté industrie. Mais dans ce cas là pourquoi mettre Android ?


Le 21/08/2014 à 15h 56







cliclem a écrit :



Euh. Ca aurait été un quad 2.3Ghz, j’aurais dit ca peut le faire mais faudra pas lui demander la lune. Là je dis c’est juste pour dépenser 130e, l’essayer une fois et le remettre dans sa boite <img data-src=" />



En se qui concerne l’usage TSE, tu m’excusera mais sous android, 4.2 qui plus est…





Si le bootloader est ouvert il vaux mieux virer android pour mettre une distribution plus classique.



Moi ce que j’ai trouvé bizarre c’est qu’ils ont mis un port série dessus.



Le 19/08/2014 à 15h 10







metaphore54 a écrit :



Petite question que sont les méfait de ces produits quand ils sont sans nicotine ni gout tabac ? question que je me pose pas pour te piéger.







Inhaler régulièrement de la fumer ou des vapeurs chaudes augmenterait les chances d’avoir un cancer de la gorge donc c’est peut être le cas pour la cigarette électronique mais aucune étude n’a été faite à ma connaissance.


Le 25/07/2014 à 14h 09







eliumnick a écrit :



T’as raison, inutile d’avoir un débat car “moi je connais”……….



En tout cas merci à ceux qui m’ont prouvé que j’avais tort, il est toujours bien d’apprendre des choses, d’ailleurs au passage si vous pouviez apprendre à millman42 à être un peu plus diplomate ça ne serait pas un mal..







C’est valable pour toi aussi. Si mon dernier post était un peut sévère c’est parque tu m’as énervé.



Et ça : “d’ailleurs au passage si vous pouviez apprendre à millman42 à être un peu plus diplomate ça ne serait pas un mal..” ce n’est pas très diplomate non plus. <img data-src=" />


Le 25/07/2014 à 12h 02







eliumnick a écrit :



Oui justement je l’ai lu….



Rien n’indique dans le pdf que la procédure de connexion au réseau la première fois est ou n’est pas initié par le téléphone.



Et pour ton 2ème paragraphe….. tiens je crois que mon mobile essaye d’utiliser la 56G, avec la fréquence 5412521 Ghz, et qu’il fait des essais toutes les 1 ns pour se connecter…



Prend exemple sur A-D : il a su trouver des documents assez clairs pour étayer ses propos.







Dans mon document la procédure de connexion à une antenne est décrite. Le fait d’être déjà connecté à une autre antenne ou pas ne change rien a la procédure de connexion. C’est pour cela que la document ne le mentionne même pas.



Après ce que j’ai dis dans mon 2e paragraphe c’est que si tous les mobiles émettent des ondes de manière chaotique pour rechercher une antenne, ils vont forcément se perturber les uns les autres. Pour que cela n’arrive pas ils ont besoin d’informations en amont. C’est là, comme c’est marqué dans mon pdf et comme te la dis Khalev qu’intervient la fameuse information de “localisation area” envoyée par l’antenne.



Sans cette requête le téléphone ne peut pas se connecter donc n’émet rien.



“Prend exemple sur A-D : il a su trouver des documents assez clairs pour étayer ses propos. ”



C’est valable pour toi aussi, je ne me souvient pas t’avoir vu documenté tes propos. Et ce n’est pas moi qui a commencé par affirmer quelque chose de faux sans aucune preuve.



Sinon j’ai autre chose à faire que de te chercher un document. Si tu en veux un cherche le par toi même, moi je connais déjà le fonctionnement de base des réseaux mobile. Si c’est vraiment ce que tu veux et pas juste troller voici le livre de référence en français sur le GSM (il existe le même par l’UMTS).


Le 25/07/2014 à 10h 05







eliumnick a écrit :



Le diagramme montre un cas différent : le mobile est déjà connecté au réseau, puis il change d’antenne.







Tu as lu le pdf ? Que tu sois enregistré sur un PSTN et que tu utilises déjà une antenne cela ne change en rien à la procédure de connexion à une autre antenne. Et c’est la même procédure pour se connecter la première fois. C’est ce qui est décrit dans le document.



D’ailleurs sinon si tous les mobiles devraient émettre pour détecter l’antenne ne connaissant pas le protocole de communication, ni la fréquence, ni les intervalles de temps, ils vont forcément se perturber entre eux et aucune communication sera possible.


Le 24/07/2014 à 19h 31







eliumnick a écrit :



Pour savoir qu’il n’a pas de réseau le téléphone émet une requête à la puissance maximale pour voir si une antenne répond ou non. Si oui il établit la connexion à la puissance nécessaire pour communiquer. Sinon il attend un certain temps (probablement en seconde pour que l’utilisateur puisse utiliser son téléphone des qu’une antenne se trouve a proximité) et réémet cette requête à la puissance maximale.







Non.



Pour information voici un diagramme de séquence de la procédure de localisation en GSM.



On va bien que au début le téléphone se contente d’écouter et mesurer la puissance des signaux qu’ils captent et qu’il commence l’inscription que après.


Le 24/07/2014 à 19h 10







eliumnick a écrit :



C’est pas l’antenne qui initie la connexion, c’est le téléphone.







Justement vu que c’est le téléphone qui initie la connexion il faut bien que les antennes publie la liste des réseaux qu’elles offre pour que le téléphone sache sur quelle réseau se connecter.



S’il n’y a rien il n’y a pas de connexion possible, le téléphone se connecte à aucun réseau et il n’y a pas démission.


Le 24/07/2014 à 16h 17







Loupton a écrit :



Invérifiables ou controversés, en quoi la médecine douce est en rapport avec l’écologie et en quoi elle pose un problème aux écologistes, moi pas comprendre.

Puis bon, la peur, les autres aussi l’utilisent pour vous vacciner ou pour vous vendre tout un tas de trucs inutiles, pour ce qui est des ondes c’est avéré, +de 15 mn par jour et tu te grilles le cerveau, mais bon comme un autre l’a dit, laissons fait la sélection naturelle…. ça vaut mieux pour les autres <img data-src=" />







Pour info les effets thermiques des ondes sont tout a fait maitrissé depuis des années (c’est les autres effets sur l’organisme qui ne le sont pas) et on est sûr qu’a la puissance et fréquence qu’on émet on ne grille (dans le sens cuir) rien. Même si on colle le téléphone 24h/24h sur sa tête.


Le 24/07/2014 à 16h 13







eliumnick a écrit :



????



Un tel portable sans réseau va émettre au maximum pour essayer de trouver du réseau…………. du coup je ne vois pas le rapport avec ton commentaire







Absolument pas un portable son réseau ne vas pas émettre. S’il ne capte pas l’onde de l’antenne ce n’est pas en envoyant des ondes qui va se mettre subitement à capter.


Le 10/07/2014 à 20h 08







bismarckiz a écrit :



La nuance est là alors, mais ton chromecast lit la vidéo à l’écran depuis le net et tu la commande depuis la tablette.



Sur la tablette avec play to (dlna) j’ai le même comportement pour l’utilisateur final. Je pilote de la tablette avec la vidéo sur l’écran de télévision, sans fil et sans dégradation de la qualité (ou des broutilles)



Effectivement ce n’est pas le chromecast qui lit mais la tablette mais le résultat final est le même. On t’as vendu un qui t’as coûté 35euros alors que de base ta télé le fais pour peux qu’elle est 4 ans.



J’utilise ça depuis plus d’un an (et ma tablette) et je cherche toujours le plus de chromecast …. personnellement je le vois pour une Apple TV avec airplay qui lit le son sur des enceintes de la pièce mais pas pour chromecast.



Je ne remet pas en cause ce que fait le chromecast, je met en cause le fait que google a pondu un truc fermé qui va pénaliser les technologies plus standards et va pénaliser l’utilisateur qui n’est pas sous Android en sortant un doublons de technologies existantes.



Je reviens sur l’exemple de VLC qui a annoncé qu’ils vont être compatible chromecast alors qu’en 2014 on doit monté une usine à bas pour diffuser en DLNA -&gt; le DLNA n’a pas un an et miracast non plus.







Non ce n’ai pas le même fonctionnement. Chromecast c’est juste un Chrome avec une api qui permet de le commander (au passage l’API est ouverte et il existe une version opensource de Chrome et en théorie on peut remplacer le navigateur par un autre donc on ne peut vraiment parler de solution fermée. Et il y a déjà des discutions pour réaliser un chromecast opensource).



A la base c’est conçu pour aller afficher des site internet sur la télé et lire du contenu vidéo comme le ferait un navigateur.



A ma connaissance je ne connais pas de site qui offre la possibilité de se connecter dessus directement en DLNA.



Le DLNA à la base c’est un standard pour partager du contenu sur un réseau (pas forcément vidéo on peut envoyé des documents à imprimer par exemple) et contrôler les équipements qui exploite ce contenu.



Il définit plein d’autre chose comme un mécanisme de découverte de périphérique mais à échouer à définir un truc essentiel les MIME types des fichiers qu’ils échangent. Ce qui fait que certains équipements DLNA ne peuvent parfois pas savoir lire du contenu d’un autre appareil DLNA alors qu’en théorie ils en sont capable.


Le 10/07/2014 à 13h 51







bismarckiz a écrit :



J’exagère en disant 10 ans mais c’est une techno qui a toujours été boycotté.



Mes mkv, mes videos youtube et toutes les videos que IE lit passent super bien entre ma surface et ma Xbox ou télé sony de 2010 en DLNA. Sans rien d’autre que le Play to. Le seul reproche ? Les sous titre qui sont souvent mal pris en charge.







Oui mais le DLNA ne permet de lire une vidéo en streaming sur un site internet. Car à la base c’est ça le rôle du chromecast.


Le 10/07/2014 à 09h 20







momoleod1 a écrit :



Quelle révolution. Miracast permet de le faire depuis un moment avec un dongle compatible qui coûte pas plus cher qu’une clef chromecast. De plus c’est standardisé. Qu’apporte Google avec SA solution propriétaire?







Le problème de miracast c’est que cela coupe la connexion internet apporté par le wifi.



De plus le mirrors sreen n’est qu’une des fonctionnalités offerte par le chromecast. A la bas ce n’est pas la même chose.


Le 04/07/2014 à 17h 10







francois-battail a écrit :



<img data-src=" />



Une varistance, un diviseur potentiométrique, un pont redresseur, une diode transil, une capa, un régulateur type 78L05 et une autre capa ; pas besoin d’une alim à découpage pour quelques mA et auquel cas tout tient dans la prise avec les LEDs. Pour les précautions c’est plutôt en cas de surtension secteur (d’où la varistance et la diode transil) et le risque d’exporter des interférences hautes fréquences directement à travers le secteur à cause de la fréquence de fonctionnement du micro-contrôleur et de la modulation PWM.







Il y a moyen d’avoir une alimentation à découpage commune pour les diodes et le micro.

Au mon avis c’est ce qui est fait. En tout cas c’est la solution utilisé dans les montages fait par des fablabs sur internet.


Le 04/07/2014 à 15h 11







Rozgann a écrit :



Oui, mais je parle d’un gradateur commandé à distance par un serveur. Le gradateur reçoit un signal en courant continu (0 à 5 V) qu’il interprète pour faire varier plus ou moins la tension du 220V (en fait il ne fait pas varier l’amplitude de la tension, il coupe plus ou moins de la sinusoïde). Donc il faut un circuit de commande en 5V pour pouvoir le commander…







A la base je rebondissais sur le commentaire kikouk en disant que cette solution était pour moi la plus économique car elle s’adapte sur un réseau standard existant et prévu pour limité le perte par effet dans le transport (haute tension).



Là tu es train de me parler d’une solution spécifique à base de plusieurs gradateur (qui coute cher comme tout les composants d’électronique de puissance) et qui ne permet pas d’utiliser des ampoules à LED (car leur alimentation est calibré pour une tension donné en entrée).







francois-battail a écrit :



Pas forcément. Il est relativement facile d’alimenter un micro-contrôleur directement à partir du 220V sans transfo (il y a des précautions à prendre toutefois), donc si le micro-contrôle reçoit un signal via CPL, il peut localement faire varier une sortie PWM (Pulse Width Modulation) qui commande un MOSFET qui commute du 220 V redressé vers le réseau de LEDs.



Avec du CPL on doit être à moins de 10 € pour les composants supplémentaires par système d’éclairage, et en veille la consommation doit être à peine mesurable (quelque µA). Le système centralisé de commande doit être relié au secteur pour pouvoir adresser les « ampoules » et peut recevoir les ordres par WiFi ou mieux (du point de vue sécurité) être connecté par RJ45 à un switch du réseau local.







C’est ce qui est fait sauf que le micro n’est pas directement alimenter en 220V (on ne peut alimenter une micro contrôleur à cette tension et il lui faut une tension linéaire et pas alternative. Je pense que c’est ce que tu as voulu dire par “il y a des précautions à prendre toutefois”) il y a une alimentation à découpage en amont (je ne sais pas si elle est isolé par un transformateur. mais à mon avis oui.).



Et ils utilisent le Zigbee à la place du CPL ou Wifi car c’est se qui consomme le moins et ça coûte pas cher. En plus cela permet d’avoir en prime un réseau maillé.


Le 03/07/2014 à 20h 34







Rozgann a écrit :



Si je comprends bien, le petit boitier qu’on branche sur une prise communique en wifi avec ton smartphone et commande ensuite les ampoules avec le protocole ZigBee.



En fait, en y réfléchissant un peu, il y a pas 50 technologies pour faire varier l’intensité d’une ampoule. Bien qu’elles soient “connectées”, elles reçoivent le même courant alternatif que n’importe quelle ampoule. Donc elles doivent simplement intégrer directement un gradateur à l’intérieur, piloté par un circuit qui reçoit les commandes ZigBee. Donc quand tu achètes ces ampoules là, de fait, tu mets un gradateur par ampoule (plus tout le circuit qui reçoit le signal ZigBee et l’interprète), sauf que là tu es obligé de changer tout ça en même temps que l’ampoule…



Donc le surcoût de la solution que je propose ne viendrait pas du matériel pour chaque ampoule (vu que tu peux continuer à mettre l’ampoule que tu veux, que tu peux changer de marque si les prix évoluent vu que tu n’es pas lié à une technologie propriétaire), ça vient de l’ajout du circuit de commande basse tension. Si tu le prévois quand tu fais une construction neuve ou quand tu refais l’électricité de ton logement, je pense que le surcoût est faible. Par contre c’est certain que greffer ça sur de l’existant c’est pas viable.







Non il n’y a pas de gradateur dans les LED vendu au grand publique il y a une alimentation à découpage.



Après je n’ai pas compris ton histoire de réseau basse tension, si tu utilises en gradateur c’est que tu es en haute tension.


Le 03/07/2014 à 17h 57







Rozgann a écrit :



La variation d’intensité lumineuse, c’est encore un truc qui concerne la partie commande. Il suffit d’un variateur (le terme exact est gradateur je crois) qui est commandé avec le circuit basse tension.



Je suis pas spécialiste du domaine de la domotique, mais j’ai fait un peu d’automatique dans mes études, et tout fonctionne comme ça dans l’industrie : un circuit de puissance et un circuit de commande qui gère les “vannes” sur le circuit de puissance. Tu peux avoir des contacteurs qui n’ont que deux états ouvert/fermé, mais tu peux aussi avoir de l’électronique de puissance qui permet des réglages plus fins. Je ne vois pas pourquoi ce ne serait pas transposable pour la domotique. C’est juste que ça demande un circuit de plus, et donc un investissement supplémentaire et un résultat moins flexible que la commande sans fil.







Du coup du doit mettre un gradateur par ampoule. Elle est chère ta solution surtout si on a ajoute le coup du réseau électrique à revoir.


Le 03/07/2014 à 11h 14







Rozgann a écrit :



Je comprends pas ta remarque. Pourquoi tu aurais besoin de changer comment tu alimentes tes ampoules pour avoir un système centralisé ? Il suffit de rajouter un second circuit de commande en 5V qui commande des contacteurs sur le circuit de puissance existant. Il ne sert qu’à actionner des contacteurs, donc très faible intensité.







Oui mais dans se cas là tu pers une partie du bénéfice des ampoules connectés. Car les ampoules connecté que j’ai vu vont plus loin que le simple allume éteint à distance. On peut régler l’intensité lumineuse.


Le 03/07/2014 à 08h 39







francois-battail a écrit :



Pas forcément. Tu as des LED de puissance à plus de 10V en vf et pour de l’éclairage on peut en mettre en série et alimenter directement en 220V redressé avec un MOSFET pour la commutation/modulation PWM au lieu d’un relais. Par ailleurs, le rendement d’un système d’éclairage LED est sans commune mesure avec des ampoules classiques.

Donc il est tout à fait possible d’avoir une tension relativement élevée et une intensité assez faible pour limiter la perte par effet Joule.







Du coup avec ta solution tu remets un système d’alimentation au plus près de la LED.


Le 03/07/2014 à 08h 06







kikouk a écrit :



Et quand l’ampoule est HS, faut changer tout le dispositif ? Si c’est la cas, c’est pas très écolo ni économique <img data-src=" />



Je militerai plutôt pour un système centralisé qui piloterai un ensemble d’ampoules conventionnelles. D’ailleurs si quelqu’un connaît un système existant (genre carte avec plein de relais) je suis preneur de l’information.







Le problème d’un système centralisé c’est que en plus de revoir toutes l’installation électrique, c’est que les LED ça marche avec une tension faible. Du coup si tu as un système centralisé qui distribue un courant tension faible, pour avoir la même puissance délivrée, tu auras un courant d’intensité nécessairement plus élevée qui va passer dans tes fils. Du coup le courant perdu dans les fils sera bien plus élevé (la puissance thermique perdu dans les fils est proportionnel au carré de l’intensité).



Ce qui fait qu’a long terme c’est plus économique de gérer toutes la partie alimentation au plus près de la LED.



En plus de ça les LED ont une durée vie largement plus élevé que les Ampoules classiques.


Le 30/06/2014 à 12h 07







arno53 a écrit :



Ne serait ce pas plus intéressant de faire évolué le protocole IMAP ou de faire un nouveau standard ? Parce que supprimé la synchro Exchange Active Sync sous prétexte que c’est proprio pour pousser une API proprio à la place de l’IMAP c’est <img data-src=" />







Non car là ce n’est pas la même chose. Il s’agit d’une API Gmail pas d’un protocole de communication. Le protocole utiliser est standard c’est du REST.


Le 13/06/2014 à 12h 13







Stoane a écrit :



Donc si je met un répéteur GSM dans une piece, comment celui-ci se connecte au réseau GSM ? Via RJ45 ?







Non, il faut percer le mur et mettre une antenne à l’extérieur.


Le 13/06/2014 à 11h 43







Stoane a écrit :



Murs en béton armé qui fait cage de Faraday, du coup obligé de tirer des cables RJ45 dans (presque) toutes les pieces.

Ce qui n’est pas plus mal au final. Par contre pour le GSM j’ai pas trouvé de solution.







Pour le GSM, tu peux utiliser un ou plusieurs répéteur GSM.


Le 10/06/2014 à 11h 06

BeOS est américain à la base il me semble. Pas français.

Le 09/06/2014 à 11h 57







Drepanocytose a écrit :



Parce que :

mobile = très près de la tête et les ondes ont une puissance en 1/r²

wifi = microondes à 2,4 GHz = une des fréquences de résonance de l’eau = action sur ton corps qui est fait majoritairement d’eau.







2.4 GHz n’est pas une fréquence de résonance de l’eau (de mémoire elle est largement plus élevé).



Le phénomène utiliser dans les fours à micro-onde ne repose pas sur la résonance mais sur un déphasage entre le mouvement de la molécule H20 et la fréquences du champs électromagnétique.



La fréquence de 2.4 Ghz est utilisé car à la puissance d’émission des fours à micro onde elle représente la meilleur compromis entre absorption et pénétration.



Avec une fréquence plus élevé tout l’énergie sera absorbée à la surface de l’aliment à cuir et l’intérieur ne sera pas cuit.



Une fréquence plus faible cuira moins efficacement.


Le 28/05/2014 à 15h 47







wagaf a écrit :



Source ?



J’ai souvent lu l’inverse.







Oui je suis curieux d’avoir les sources aussi. De mémoire la puissance d’émission en WiFi c’est 30mW en moyenne avec un maximum légale de 100mW. Alors que pour le GSM c’est de l’ordre de 600mW.


Le 13/03/2014 à 08h 34







ar7awn a écrit :



dont des entreprises américaines, notamment pour les pilotes et parties du noyau non open source.







Il n’y a pas de partie non open source dans Linux.



Certaine distribution ajoute en plus des morceaux binaires propriétaires appelé blobs mais cela ne fait pas partie de Linux. D’ailleurs aussi bien sous Debian que sous Ubuntu ils sont isolé dans un paquet à part et non installé par défaut.



Cela ne change rien à ton propos mais c’est juste pour éviter la confusion.


Le 12/03/2014 à 13h 57







lateo a écrit :



Balance le lien si tu l’as! <img data-src=" />

Tout ce qui touche à lxc m’intéresse en ce moment <img data-src=" />







Pour l’instant cela existe seulement pour serveur https://www.docker.io/learn_more/ mais il y aussi des devs de suse ou red hat je ne sais plus qui se penche sur la question mais pour du desktop cette fois-ci (je n’ai pas réussi à retrouvé le lien).


Le 12/03/2014 à 13h 04







ar7awn a écrit :



non gobuntu est un dériver entièrement libre, seul une partie d’ubuntu est libre le reste est proprio







Ubuntu est libre si on fait exception des blog dans le noyau.



Après ce lui reproche les libristes (la FSF) c’est ça :



Ubuntu GNU/Linux



Ubuntu propose des dépôts spécifiques de logiciels non libres, et Canonical recommande des logiciels non libres et en fait la promotion sous le nom d’Ubuntu dans certains de ses canaux de distribution. Ubuntu propose l’option d’installer uniquement des paquets libres, ce qui signifie qu’elle propose également l’option d’installer des paquets non libres. De plus, la version du noyau Linux présente dans Ubuntu contient des blobs de micrologiciel.



Les conditions d’utilisation de la marque Ubuntu interdisent la redistribution commerciale de copies exactes d’Ubuntu, refusant ainsi une liberté importante à l’utilisateur.


Le 12/03/2014 à 13h 00







lateo a écrit :



<img data-src=" />



autre “souci” : quand on se repose sur une lib fournie par le système : sous linux le rythme des màj est très élevé, a fortiori sur les distros en rolling release.

ça demande aux dev une veille qu’ils n’ont pas l’habitude de faire sous windows, dont les “bases” ne bougent que lors de la sortie d’une nouvelle version (et encore).



En fait je crois que ce qui les dérange vraiment, c’est ça, le fait que sous linux ça bouge tout le temps, et qu’il faut suivre tout ça de près, sous peine de passer pour un guignol <img data-src=" />

Ce n’est pas pour rien que les boîtes qui font du soft commercial sous gnu/linux “fournissent” (voire intègrent directement dans leur binaire…) presque toujours leur propre version des libs qu’ils utilisent (on s’assure une tranquillité et on “masque” la version de la lib utilisée au tout venant).







+1

J’ai même vu des boites distribué des toolchains sous forme binaire redistribuer leur libc et même leur linker dynamique.



Mais en faite quand on y regarde de plus près c’est un peut ce qui est fait sous Windows. Par exemple un programme qui a besoin de Qt va être livré avec les dll de Qt.



Sous Linux il y a un projet qui apporte un début de solution à ce problème.

L’idée est de proposer des conteneurs (LXC) utilisable sur toutes les distribution qui contiendront un environnement standard et stable qu’on pourra plus ou moins enrichir.



Les applications seront après lancé dans le conteneur.



L’avantage c’est qu’on donc gérer différentes bibliothèques au sein d’un même système et tout de même gardé la possibilité de pouvoir facilement appliqué une mise à jour de sécurité facilement.