Boa Treize a écrit 3449 commentaires

c'est la même puce graphique que les autres CPU intel

Ah ben non, les cœurs graphiques Intel, c'est assez varié, les fonctionnalités s'accroissent de génération en génération, et au sein d'une même génération, les capacités disponibles dépendent de la gamme de processeur / cœur graphique. (Un peu comme les CPU en fait.)

C'est pas parce que c'est géré par un seul pilote qu'il n'y a pas une grande variété de matériel derrière. Voir la grande liste de Wikipedia par exemple : https://en.wikipedia.org/wiki/List_of_Intel_graphics_processing_units

Depuis plusieurs versions Linux, l'équipe du pilote Intel s'est embarquée dans un grand travail de rework / nettoyage du code (notamment autour de la gestion de l'atomicité de la gestion des modes graphiques), ce qui ne s'est pas fait sans régressions.

Le curseur laisse plein de traînées sur l'écran. C'est apparu lors d'une mise à jour du noyau 4.2. J'ai essayé Kubuntu 16.04 (noyau 4.4), et c'est pareil. Du coup je met plus à jour le noyau, en attendant d'aller essayer des versions encore plus récentes. C'est sur un NUC, donc une plate-forme un peu spécifique.

Et vous, avez-vous été concernés par des bogues suite au passage de la version 2 à la version 3 de GTK+ ?

Carrément oui, c'est pas la joie sous Kubuntu 14.04 ! Tooltips en texte noir sur fond gris sombre, et surtout boîte de dialogue de sélection de fichiers bien dégradée : au lieu d'être simplement sélectionnés, les fichiers s'accrochent au curseur… Il faut les larguer avant de cliquer sur Ok, pas très intuitif. Dommage de subir ça dans une LTS !

Manifestement le problème ne se pose pas sous Kubuntu 16.04. Pas encore essayé, car le pilote graphique Intel a une régression sur les versions récentes de Linux (y compris celle de la 16.04) sur les NUC récents… Après des années de tranquillité sous GNU/Linux, c'est pas très agréable en ce moment.

Plutôt complet en effet, et d'excellente qualité ! Si le compteur Linky vous intéresse, c'est une lecture indispensable. Merci d'avoir posté le lien !

Pour 20€ au brico tu as des petits boîtiers à brancher directement sur ta prise et sur laquelle tu peux brancher ton appareil (ou ton bloc multiprise) et zieuter la consommation, faire des stats, etc

Oui, et c'est déjà un effort significatif (acte d'achat, faire les mesures pour les divers appareils, mettre en place et tenir à jour un fichier de suivi des mesures), alors qu'ERDF et le fournisseur d'électricité proposent cela gratuitement et sans effort pour le client.

De plus, ces appareils ne sont pas toujours précis (notamment sur les charges électriques qui varient rapidement), et cette imprécision est mal documentée ; alors que côté compteur, même s'il y avait une imprécision, c'est de toute façon la valeur facturée qui est tracée, en pratique la seule qui compte pour le client.

la mesure en temps réel

Ce n'est pas en temps réel : la transmission dure 30 secondes environ, donc au mieux ils pourraient faire une mesure par minute. Actuellement (et rien d'autre n'est prévu à ma connaissance), c'est une fois par jour, et ça nécessite déjà une énorme infrastructure pour collecter l'ensemble des compteurs de manière fiable.

Par ailleurs, l'unité de mesure est le kWh, donc même avec une mesure par minute, le compteur ne ferait que répéter la même valeur de nombreuses fois de suite (pour faire plus d'1 kWh par minute, il faut consommer plus de 60 000 W…).

non pas de ta consommation électrique et mais de tes habitudes de consommation

Je ne vois pas comment le compteur pourrait transmettre tes "habitudes de consommation", ni même ce que tu entends vraiment par là. Il mesure des kWh c'est tout.

transmises à EDF

ERDF. (Petite nuance, mais quand même soyons précis.)

la non maitrise des fonctionnalités du compteur dont la liste restera au bon vouloir d'EDF via des mises à jour arbitraire du firmware

Le firmware restera en tout état de cause limité par les fonctionnalités du matériel, et notamment de sa connectique : il ne peut mesurer que le total de ton installation, et il ne peut envoyer qu'un signal de commande on/off sur certains circuits (ceux que tu auras fait relier par un électricien, par exemple chauffe-eau, chauffage, etc.). Rien ne t'oblige (hors contrat et donc tarif adapté) à brancher des appareils sur ces circuits commandés. Tu peux tout mettre sur le circuit principal, et le fournisseur d'électricité ne peut que… te couper l'électricité. (Ce qui n'est pas nouveau.)

demain, par exemple, celle des données qui transitent par CPL sur ton installation privée

Faut calmer un peu la paranoïa, là. Il y a de nombreuses manières plus économes d'espionner les gens qu'en pompant tout leur CPL (et bonjour l'infrastructure de dingue à mettre en place). En tout cas, il te suffirait de mettre un filtre CPL en aval du compteur, pour que rien ne "remonte" de ton installation. Et puis bien sûr, si tu tiens à la sécurité de tes données, tu ne les envoies pas à tous tes voisins par CPL, tu utilises de l'Ethernet.

l'interdiction d'alimentation de matériel ayant une signature de consommation spécifique

Le compteur ne peut que commander certains circuits que tu as branché toi-même (par l'intermédiaire d'un électricien). Il ne peut pas décider de couper un matériel spécifique, sauf si tu as fait un branchement spécial pour ça.

… et c'est plutôt pas mal.

Pour moi le principal avantage est de voir en direct sur le compteur la consommation électrique de l'installation (ce que les compteurs récents permettaient déjà de faire), c'est instructif surtout quand on pense que tout est au repos et qu'on voit qu'on bouffe quand même 100 W. Bien sûr on peut faire ce même genre de mesure avec un wattmètre, encore faut-il l'acheter et faire la tournée de chaque appareil…

Le relevé quotidien ne me gène pas sur le principe, avoir la courbe de consommation peut être intéressant (notamment suite à l'achat d'une carte graphique, exemple personnel…). Encore une fois, un bricoleur peut faire ça avec un Raspberry Pi et quelques capteurs, là c'est fourni clés en mains pour Monsieur et Madame Tout le monde.

Ceux qui se plaignent "des ondes" me font doucement marrer (ou m'énervent un peu), le compteur fait une brève émission quotidienne (30 secondes si j'ai bien lu), et c'est tout. Quant à la collecte de données, il faut d'abord se débarrasser de son téléphone portable avant de commencer à aborder ce sujet, sinon on n'est pas crédible pour deux sous. Bref, j'hallucine un peu de voir des tags anti-Linky fleurir à droite et à gauche, et des campagnes "d'information" sur les "ondes" se mettre en place. L'obscurantisme a de beaux jours devant lui.

C'est amusant de voir que le jour même où je décide d'abandonner Clementine, une nouvelle version sort. Mais manifestement, cette version ne corrige pas tout ce qui m'irrite, donc ne me fera pas changer d'avis.

Mes sérieux problèmes avec Clementine :

• Mauvaise gestion des bibliothèques musicales sur support amovible. Si j'ai le malheur de démarrer Clementine alors que mon disque dur externe est débranché, il « oublie » les morceaux qui s'y trouvent. Lorsque je m'aperçois de mon erreur et branche le disque dur externe, Clementine scanne à nouveau intégralement toute ma collection de musique…

• Mauvaise gestion des tags et des albums. La gestion de Clementine est simpliste voir bête, et non paramétrable. Manifestement, à partir du moment où deux morceaux ont le même tag ALBUM, ils sont considérés comme faisant partie du même album, indépendamment de tout autre critère (artiste, année, arborescence des fichiers). Dommage quand on a plusieurs Master Serie de divers artistes, ou quand Daft Punk et Mike Oldfield ont tous les deux sorti un album Discovery.

• Choix d'arborescence assez limités. Et autres irritants mineurs.

Je suis tombé un peu par hasard sur Quod Libet en cherchant un outil pour taguer mes fichiers M4A, et j'ai été conquis ! Scan rapide, recherche/filtrage très performant de la collection de musique, fortes capacités à personnaliser l'affichage… Pour l'instant très satisfait de ce lecteur injustement méconnu.

si ms pense que ce qui attire les gens vers OS X c'est bash, ils vont là être déçus du voyage

C'est pas bash, c'est la capacité à exécuter tous les binaires Linux en natif. Les outils, les serveurs, etc.

Et vu que j'ai entendu dire que MacOS X était devenu un peu moins sympa pour les devs en ligne de commande ces derniers temps, c'est peut-être le bon moment pour sortir ça.

Par exemple (car je n'ai pas dit que c'était forcément une mauvaise idée), un stockage sur des serveurs dédiés à la diffusion de données statiques (avec CDN, possiblement un coût plus faible par GiB, etc.) peut être plus avantageux.

c'est quoi des "blobs" ?

En fait c'est assez proche du chef d'œuvre du siècle dernier que tu cites. L'idée, c'est que c'est un gros tas d'octets informe, et t'es bien en peine d'en dire plus. Le sous-entendu c'est que tu n'as pas le code source, tu sais pas ce que ça fait, c'est potentiellement hostile ou faillible, bref c'est désagréable.

C'est un terme notamment employé dans le cas de pilotes logiciels, où de plus en plus souvent, du code binaire est chargé dans les puces du matériel piloté, lors de l'initialisation. Autant on peut avoir le code source du pilote qui dialogue avec le matériel, autant on n'a souvent pas le code source du code qui s'exécute dans le périphérique.

Par ailleurs, en base de données, ce terme existe pour désigner le contenu d'une colonne qui contient un ensemble d'octets arbitraire, potentiellement très grand, que la base de données doit stocker spécifiquement (souvent sous forme de fichiers à part) et qu'elle ne peut pas beaucoup traiter en SQL (rien d'autre que stocker une valeur et la ressortir plus tard). Il peut par exemple s'agit d'une image que l'on stocke dans une colonne (même si c'est pas forcément une bonne idée). Pas de connotation négative dans ce cas, et un acronyme qui a été défini en ayant bien en tête le film dont tu parles : BLOB, Binary Large OBject.

le wifi est simplement devenu une commodité! Combien de voitures low-cost viennent encore sans radio?

À ce sujet, ma voiture actuelle (pas low-cost) peut être client Wi-Fi (liste des réseaux du voisinage), ainsi que point d'accès Wi-Fi pour les appareils à bord. (J'ai juste vu la fonctionnalité, pas testé.)

C'est également disponible sur Ubuntu depuis hier soir (au moins sur 14.04 LTS).

par exemple secure boot qui vous oblige à utiliser Windows

Euh non : tu peux installer tes propres clés, et signer ton propre noyau. D'ailleurs Ubuntu distribue un chargeur UEFI signé, tu peux booter en UEFI Secure Boot sur une machine qui n'a jamais vu un octet Windows sur son disque dur.

Tu pars sur l'idée "données irremplaçable et pas de backup", ça veut juste dire que la personne perdra un jour ou l'autre (panne matérielle DD, vol…) ses données irremplaçable, alors vaut mieux maintenant (pour apprendre avant d'en avoir trop d'irremplaçable) que plus tard.

Heu non, c'était pas vraiment mon argument. Je répondais par un trait forcé (curseur placé complètement sur l'importance des données, carte mère ramenée à une simple question de budget) au trait forcé inverse qui avait été posté auparavant (qui disait que ça n'a aucune importance d'effacer son disque dur car l'auteur du commentaire a des backups d'excellente qualité, et que bloquer la carte mère, c'est beaucoup plus grave).

En réalité je pense que les deux sont des problèmes majeurs, et ne souhaite subir ni l'un ni l'autre. Et je suis tout à fait d'accord avec Lennart pour dire que l'un comme l'autre sont actuellement assez faciles à faire par quelqu'un à qui on a donné un terminal en root.

D'ailleurs, si cette personne est hostile, il sera trivial de remonter en lecture-écriture les variables UEFI problématiques et de les démolir quand même. La protection demandée ne concerne donc que les administrateurs qui font des rm -R dans /sys ; un petit pansement sur une grosse blessure.

Pour moi le problème est clairement à régler à plus bas niveau (carte mère en premier, et noyau pour protéger les cartes mères pourries).

Tu es complètement tombé dans le troll de Lennart.

On compare rm /dev/sda et rm /sys/sys/firmware/efi/efivars/qqch.

Il n'y a pas de troll, et la comparaison entre deux rm, c'est toi qui l'a imaginée. Indique-moi où dans le lien indiqué Lennart parle de faire un rm de /dev/sda ! Cite-donc, sans interpréter !

en supprimant un fichier virtuel dans /sys, ce qui est sensé être comparable à supprimer le fichier /dev/sda par exemple

Censé… Selon quelle norme, quelle règle, selon qui ? Il y a des trucs dangereux qui traînent dans /proc et /sys, des variables en écriture seule un peu inquiétantes, des fichiers pas vraiment fichiers, de quoi aller taper très fort dans les périphériques USB et PCI il me semble… Qui va aller s'amuser à faire des rm là-dedans ? C'est très différent d'un /dev qui contient essentiellement des device nodes très classiques.

rincer un disque dur n’a pas la même conséquence que de rincer un firmware de carte-mère

Non en effet, dans un cas on perd toutes ses données (irremplaçables), dans l'autre on rachète une carte-mère (de meilleure qualité, au passage). Alors oui, si tu as des super backups et pas d'argent, planter la carte-mère ça peut être pire, mais je pense que pour la plupart des gens, c'est l'inverse.

Tu n’as surtout qu’une représentation, cette sauvegarde n’a pas vraiment de sens.

Bah euh si ! Ce sont des fichiers réguliers tout à fait banals d'un point de vue Unix. Tu lis leurs octets (sauvegarde), tu écris leurs octets (restauration). C'est comme ça que j'ai récupéré mon giga de RAM : en restaurant une sauvegarde d'un paramètre du BIOS. (Bon, c'était à partir d'une variable de sauvegarde, mais conceptuellement, j'aurais aussi bien pu réécrire ces octets à partir d'une sauvegarde externe.)

Là où la sauvegarde n'a peut-être pas de sens, c'est que je ne suis pas sûr que tous les paramètres du BIOS sont bien exposés dans les variables UEFI (même s'il y en a infiniment plus que dans l'IHM du BIOS). Donc restaurer les variables UEFI (tout à fait faisable) ne remet pas forcément ton BIOS dans l'état où il était au moment de la sauvegarde (si des variables non-UEFI ont changé).

ça ne me rendra pas mes données si je restaure le fichier /dev/sda après avoir réécrit le disque…

/dev/sda n'est pas un fichier régulier, il y a une confusion sémantique dans tes commentaires. Si tu parles de sauvegarder et restaurer l'entrée « sda » du répertoire « dev », effectivement, ça n'aura aucun effet sur les données du disque dur. Maintenant tu me parles de sauvegarder et restaurer /dev/sda, je pense immédiatement à la commande dd, et ça marche très bien.

Et toi tu n'as pas forcément tout compris non plus… Lennart a écrit :

We also expose /dev/sda accessible for root, even though it can be used to hose your system.

Ce qui se traduit par :

Nous exposons également /dev/sda accessible à root, bien qu'il puisse être utilisé pour planter votre système.

Et il a tout à fait raison : il suffit d'un dd if=/dev/zero of=/dev/sda, et boum, les données sont perdues.

Donc ton point 1, ton point 2, l'essentiel de ton emportement, ben c'est complètement à côté de la plaque. (Et pour ton point 3, ben d'une part c'est sauvegardable, c'est l'intérêt de l'avoir sous forme de fichiers ! Et d'autre part si c'est perdu, il devrait être facile de repartir sur des valeurs par défaut dans le BIOS.)

Ah oui, en effet, j'étais resté au niveau des fichiers UEFI eux-mêmes.

Péter sa carte mère

La carte mère n'est pas (ou ne devrait pas) être pétée. Juste un reset des données à faire, normalement, ou un flash du BIOS au pire. Si la carte mère ne permet ni l'un ni l'autre, c'est elle qui a une faille.

Que l'OS puisse aller modifier les données UEFI, ben c'est l'objectif quand même. Que la carte mère ne le supporte pas, c'est pas forcément la faute de l'OS. Bien sûr, s'il y a des cartes mères qui gèrent mal, on peut imaginer que l'OS le sache et les gère spécialement, ce ne sera pas la première liste de contournements et de cas spéciaux que l'OS gère.

Ça empêcherait toutefois la modification des variables depuis un script shell

Ou à la main, avec un bon vieux coup de xxd. Ça m'a déjà été bien utile pour récupérer de la RAM "perdue" par le BIOS, alors qu'avec des ioctl, c'est sérieusement moins abordable. Bref, c'est très bien de les avoir sous forme de fichiers, faut juste faire attention à pas déconner en root.

Ne pas installer systemd c'est une autre solution.

Rien à voir ! Je n'ai pas systemd, et mon Ubuntu a les variables UEFI en lecture/écriture (pour root).

Et puis de toutes façons, root il s'en fout normalement des attributs de lecture/écriture. chmod 0 et root passe quand même, root c'est plus fort que toi (sauf si le noyau dit non, ce qui devrait être le cas pour certaines variables UEFI).

Et puis je suis bien content de pouvoir écrire dans certaines variables UEFI, ça m'a permis de récupérer 700 Mo de RAM que le BIOS avait "perdu" à cause d'un bug idiot dans chez Intel. (Il m'en reste 200 ou 300 Mo à reprendre d'ailleurs, mais c'est pas facile.)

Je pense (peut-être) que cela veut dire que le jeu s'est fait sans handicap.

Quand deux joueurs de force différente s'affrontent au Go, le plus faible reçoit comme avantage des pierres placées de manière prédéterminée avant le début de la partie. Cela lui donne un avantage au démarrage, qui compense l'écart de niveau.

Je crois que des IA avaient déjà gagné contre des professionnels au Go, mais en bénéficiant d'un handicap. Cette fois-ci, les deux joueurs étaient considérés de force égale. Au final, c'est peut-être l'humain qui aurait pu bénéficier d'une ou deux pierres bonus en début de partie…

Effectivement, quand on cherche, on trouve facilement l'info :
http://www.usine-digitale.fr/article/au-bout-du-rouleau-pixmania-ne-livre-plus-ses-clients.N376127

Faut encore avoir été prévenu, merci.

Oui j'ai vu ça, mais il a un gros défaut pour moi : il ne supporte pas que la collection de photo se déplace dans l'arborescence des fichiers. Il stocke des chemins absolus dans sa base de données. Malheureusement dans mon cas, la collection se déplace selon le PC que j'utilise.