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 " />

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. " />

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 " />



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 -> 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 :

" />

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 " />

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 " />



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! " />
Tout ce qui touche à lxc m’intéresse en ce moment " />



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 :

" />

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 " />
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.

Le 04/03/2014 à 16h 30

Eleos a écrit :

Bonjour, j’ai réalisé un benchmark de la nouvelle gamme VPS, il est dispo à cette adresse :http://chaintreuil.me/nouvelle-gamme-vps-2014-firstheberg/

@coket

Un Vcore est l’équivalent d’un core de processeur ^^



Non un Vcore avec openVZ est au mieux l’équivalent d’un core de processeur.

En faite derrière c’est un ordonnanceur de type “Fair”.

Le 27/02/2014 à 13h 59

white_tentacle a écrit :

Pourtant, c’est très clair. Oui, la NSA introduit des backdoors à plusieurs niveaux dans le noyau linux.

Et rassurez-vous, pas qu’au niveau soft, au niveau hard aussi (le générateur « aléatoire » révolutionnaire intégré aux cpus intel est vraiment soupçonné d’obéir à des caractéristiques très claires et connues de la NSA). Et étrangement, il y avait eu des discussions très enflammées quand un dev kernel a refusé de l’intégrer parce qu’il ne lui faisait pas confiance…

On peut encore parler de la technologie computrace, dont l’utilité pour l’acheteur est douteuse mais qui est un formidable outil d’espionnage.

Ah, et faut pas croire que les BSDs ne soient pas concernés.



Linux ne se base pas sur une source par faire de l’aléatoire donc même si le nombre donné par le générateur de nombre aléatoire n’est pas aléatoire, on ne peux exploiter de failler avec cela sauf si toutes les autres sources le sont aussi.

Pour des backdoors dans Linux source ?

Le 27/02/2014 à 13h 56

ledufakademy a écrit :

C’est faux.
Une simple “erreur” d’index sur un malloc (style j’ai pas fais exprés), et tu as ta faille de sécu pour qui sait la provoqué …

j’ai fait suffisamment de dev. pour savoir cela.



Heu non tu ne peux rien avec ça à cause de la MMU et une erreur d’index c’est détectable par les outils d’analyse de code statique.

Le 30/01/2014 à 16h 47

Dans la liste des erreurs : “Cland est désormais le compilateur par défaut”
C’est Clang le compilateur par Cland.

Le 12/12/2013 à 13h 42

metaphore54 a écrit :

Il y a bien quelqu’un qui va réussir à bidouiller ça, non ?



Non, sans les sources c’est impossible.

Le 12/12/2013 à 13h 26

pi314 a écrit :

hmm, au boulot il y a une vieille PS3 sans mise à jour. Vais-je perdre mes vacances à tenter de mettre steamOS dessus ? " />



Impossible, SteamOS n’est pas compatible avec l’architecture PowerPC du processeur de la PS3.

Le 05/12/2013 à 20h 01

Jean_Peuplus a écrit :

C’est beau de rêver. Steam s’intallera sans problème, mais dire que tous les jeux se lanceront sans problème sur toutes les distribs…

Faut jamais avoir essayé linux de sa vie.



Pour l’instant je n’ai pas rencontré de problème sur Arch.

Le 02/12/2013 à 16h 40

Tornado_OLO a écrit :

Fais par des passéistes, pour des passéistes.

Choisir de capitaliser sur une interface vieillissante et très peu évolutive est la raison pour laquelle cette distrib ne percera pas.
Gnome 2 a plus de 10 ans, il serait temps de voir plus loin.



Cinnamon est basé sur Gnome 3 pas Gnome 2.

Le 28/11/2013 à 12h 41

corsebou a écrit :

C’est pas “software” mais firmware…

Ensuite tu interrompts le process tu peut bricker ton appareil…
" />
.


Non tu ne pas supprimer le bootstrap qui permet de réinstaller le bootloader.
Et le bootloader c’est du soft.

Le 18/11/2013 à 15h 17

tnetennba a écrit :

Je suis surpris que personne n’ait mentionné (au moins dans les premiers commentaires) un papier de Kenneth Thompson (qui s’y connaît un peu en OS " /> ) sur les portes dérobées :http://fr.wikipedia.org/wiki/Porte_d%C3%A9rob%C3%A9e#Le_cas_du_compilateur_C_Uni…:_Trusting_Trust

Le fait est qu’un code open source peut être totalement irréprochable, mais si la porte dérobée est insérée dans le code objet via le compilateur, qui s’en apercevra ?

Alors, les mauvaises langues diront que les compilateurs aussi, sont open source. Qu’à cela ne tienne ! Tout compilateur a lui-même besoin d’être compilé. Créons donc un compilateur bis qui insère, dans le code objet des compilateurs, une ligne dont l’exécution insère une porte dérobée.

Tout compilateur compilé à partir de notre compilateur bis, et tous les suivants, posséderont la porte dérobée.

Problème de l’œuf de et de la poule me direz-vous ? Oui mais Kenneth Thompson avait la possibilité de créer un tel compilateur bis dans les années 70, celui à partir duquel tous les suivants ont été compilés.

Et même en supposant que Kenneth, dont on comprendrait mal qu’il soulève cette possibilité s’il l’avait commise lui-même, n’a pas inséré une telle porte dans le compilateur originel, rien ne garantit que la NSA n’ait pas approché les principaux développeurs de compilateurs pour insérer une telle porte, à un moment ou à un autre ; porte qui se propage depuis sur tous les compilateurs suivants… et les logiciels.



Saut que gcc est compilé avec gcc. La première version date 1987 et a été compilé avec un compilateur universitaire où le code été aussi lisible.

Mais je pense qu’introduire une backdoor dans gcc est beaucoup plus facile à faire que Linux car il est moins relus et est devenu difficile à lire.

Le 18/11/2013 à 13h 28

Shyfer a écrit :

Dites, c’est bien beau d’avoir un OS open-source/vérifié etc…
Mais peut-être qu’il faut regarder plus bas : les drivers, sont-ils open-source ? Dans la majorité des cas, non. Les BIOS/firmware sont-ils open-source ? non.
Alors en plus de l’OS, il faudrait penser à regarder TOUTES les couches logicielles. Parce que bon, ça ne sert a rien d’avoir des données chiffrées sur son disque si derrière la carte mère/processeur et carte réseau ont des backdoor …
Donc bref, un système 100% secure, bah ça n’existe pas :)



Oui sous Linux les drivers sans majoritairement open source. Et l’UEFI ne pas faire grand fois l’OS lancé. A part à la limité désactiver le secure boot.

Le 18/11/2013 à 13h 08

seblutfr a écrit :

Le problème c’est qu’il y a beaucoup de “si” dans ton argument. En effet, si quelqu’un veut, il peut relire et analyser tout le code source linux. Dans la réalité, ça n’est pas fait, tout comme les pirates ne passent guère par le code source pour trouver des angles d’attaque.
L’exemple de Resman reste valable : on trouve des bugs et autres soucis dans des bouts de code open plusieurs années après leur origine.

Donc “pouvoir vérifier” est une chose, “vérifier” en est une autre.



Si chaque nouveau morceau de code est systématiquement relu et testé.

Le 18/11/2013 à 12h 50

okeN a écrit :

Je pense que la NSA a les moyens de forcer quelqu’un à mettre un backdoor dans son programme. Je vois pas bien comment Linus aurait pu refuser là où google, ms, et autre n’ont pas pu. Et quand bien même Linus aurait trouvé le moyen de refuser, c’est probablement pas le seul à avoir été contacté.
Faut pas s’attendre à des miracles pour Linux, quand bien même le code est ouvert il est impossible de tout vérifier et d’être sûr à 100%.



Faux le processus d’approbation de tous ajout de code dans Linux est relus plusieurs fois et par plusieurs personnes.

Et si le code porte sur un endroit stratégique comme se serait le cas pour y placer une backdoor il va être facilement relus plus d’une centaine de fois.

Le 15/11/2013 à 16h 28

coket a écrit :

Ben non. D’ailleurs on l’a toujours sur BB10, et ce doit être le cas sous Windows aussi je présume.

Tout ça ressemble étrangement à une façon simple de faciliter le travail de la NSA " />



En faite c’est ça que je ne comprend pas. Et surtout le lien avec ce que j’ai dis juste au dessus que tu as mis en citation.



coket a écrit :

Pourquoi tu parles d’entreprise maintenant? Enfin, passons, pas trop le temps cette aprem…


Parce que on parle de Mme Michu et Mme Michu se contente de se qu’il y a sur son téléphone. C’est à dire l’application SMS qui a été mise par l’entreprise qui fabriqué le téléphone.