Aissen a écrit 325 commentaires

Tout en sachant que cette stratégie pourrait être la même que celle utilisée par NVIDIA pour le Tegra, étant donné les contributions DRM à nouveau qu’on a vu récemment. Si le système fonctionne, il y a fort à parier que d’autres fabricants de GPU (surtout ARM) suivent dans la même voie.

Concernant les cartes desktop NVIDIA, je ne pense pas qu’ils adoptent cette approche étant donné que leur driver desktop fonctionne plutôt bien (par rapport à fglrx).

Pour info, ils devraient choisir la GPL(v2?) car le logiciel link avec ffmpeg:
https://github.com/popcorn-time/popcorn-app/issues/175

Le gros problème de ce genre de logiciel, c’est qu’il utilise des méthodes qui ne respectent pas le swarm… En effet, le téléchargement séquentiel des données en torrent et fortement déconseillé, car il nuit à la disponibilité des chunks plus on va vers la fin. Ça ne m’étonnerai pas que les principaux auteurs de logiciels de torrent et/ou trackers décident de bannir les clients basés sur peerflix comme Popcorn Time.

Plus explicitations:
http://wiki.vuze.com/w/Sequential_downloading_is_bad
https://trac.transmissionbt.com/ticket/452

Pour LinuxFR, les I/O c’est pas mal aussi ?

Oui. Peu de télés 3D supportent ce mode (sur les deux yeux) de split, très récent.

Edit: il est possible de hacker des lunettes assez facilement pour les télés à écran polarisés (moins répandues que ceux à lunette actives…) http://www.instructables.com/id/3D-TV-Split-Screen-Gaming-SimulView/

Je suis d’accord avec le parent; j’ai plusieurs fois pensé à contribuer à weboob, mais pour des questions d’image c’est juste pas possible. Je pense que le fondateur de budget-insight (je sais plus si c’est toi moules) devrait s’en inquiéter un petit peu.
C’est rigolo, mais aussi rigolo qu’un boulet de 100kg sur lequel on aurait écrit des blagues sexistes pour pas les oublier, et qu’on aurait accroché à sa cheville et jeté la clef au fond de l’océan, alors qu’on cherche à échapper aux fousdinosaures qui veulent nous tuer sur une île du Pacifique.

Effectivement, merci de la précision! Ça ne change rien à l’idée de fond néanmoins, les applis ne sont pas portées sans effort, il faut adapter la workload à la cible.

Personnellement, je me demande comment ça se fait que, de nos jours, on n'imagine pas le processeur en même temps que le logiciel qui va tourner dessus.

Tu veux dire comme chez Apple ?

Troll à part, avant qu’ils se rachètent une team de design hardware, c’était les seuls à miser sur le GPU et pousser leur fournisseur (Samsung) à investir là dedans; kit à ce que ça prenne une place très importante sur le die; aujourd’hui on se retrouve avec des surfaces démentielles, égalées uniquement sur des puces de consoles de jeux. Ils ont été les premiers à miser sur les CPU 64-bits ARM (qui ne sert pas qu’à adresser plus de RAM), et commencent à customiser leurs cœurs ARM (comme Qualcomm) pour tirer encore plus de perfs. Sans compter qu’ils vont certainement designer leur propre GPU et lâcher Imagination à n+2 vu leurs efforts récent en recrutement.

En face, peu de monde a les moyens de faire la même chose, et ceux qui en ont les moyens ne semblent pas vouloir s’en préoccuper. On va vers une concentration des fabricants de processeurs mobiles assez inquiétante.

Je suis assez sceptique; j’étais à la conférence sur le MPAA-256 de Kalray à l’ELC (slides), et je dois dire que si il y a des bonnes idées, c’est loin d’être la révolution annoncée dans le discours marketing, ou encore dans cette news.

Déjà, il est bon de noter que du à l’architecture, les OS conventionnels ne peuvent tourner sur les 256 cores (l’interconnect ne le supporterai pas). Linux tourne sur seulement 4 cœurs, et les autres sont accessibles via une interface particulière, un peu comme on enverrai des shaders sur un gp-gpu ou un firmware sur un microcontrolleur. Donc déjà ça veut dire que vos applications traditionnelles (erlang, go, openmp…) ne vont pas profiter du cluster sans effort. Il faudra les réécrire; même si ceux qui bossent sur des HPC ont déjà l’habitude de ça.

Ensuite, si son positionnement semble intéressant par rapport aux GPU, dans les mondes des HPC je ne le vois pas concurrencer les Intel Xeon-Phi et leur future génération Knights Landing, qui saura, comme le MPAA-256, être utilisé à la fois en tant que CPU maître et CPU d’offload sur une carte PCI-E. Et je ne parle même pas de la compétition de Tilera et al, que je connais moins bien.

Cela-dit, je leur souhaite toute la réussite possible dans ce domaine assez concurrentiel, où il y a encore tout à faire…

Dans un cas comme ça, on peut quand même récupérer les données perso sur un téléphone, avant même de débloquer le bootloader (suffit de monter le téléphone depuis un ordinateur)

Ils sont pas bête, on peut pas monter un téléphone qui est verrouillé. Donc ça protège effectivement les utilisateurs.

J’ai utilisé l’installeur SteamOS en démarrant sur une clef USB avec syslinux au lieu de Grub2/UEFI, ça a très bien marché. Donc non ce n’est pas vraiment limité à UEFI, mais c’est vrai qu’il n’y a aucune instruction fournit dans l’image de base.

Même gdbtui cité par le parent, qui est intégré en standard à gdb et affiche dans plusieurs fenêtres ncurses les registres et le code. Ça fait déjà deux choses sur les trois demandés dans le journal. Quelqu’un se dévoue pour faire une fenêtre qui affiche la stack ?

En attendant, NewsBlur marche toujours aussi bien. C’est libre, et si on veut pas l’héberger, on supporte un dev indépendant. D’ailleurs je poste ce commentaire depuis NewsBlur.

Le GMA600 de l’Atom a pas de drivers libres pour l’accélération graphique(2D/3D/vidéo):
https://linuxfr.org/users/aissen/journaux/attention-aux-derniers-intel-atom

D’après Snowden, "Encryption works".

Après à vous d’interpréter… La faille peut-être dans l’ordinateur qui a la clef, ou ailleurs.

Excellente question, qui contient déjà en partie la réponse. Déjà je me suis trompé dans le journal, et netcat-traditional ne supporte tout simplement pas de proxy donc seule la variante netcat-openbsd est valable. Il est conseillé d’utiliser tsocks pour contourner ce problème.

Quant à la résolution, je peux me tromper, mais il me semble que netcat la réalise avant d’utiliser le proxy:
http://sources.debian.net/src/netcat-openbsd/1.105-7/socks.c#L72

Le bilan c’est qu’il faut préferer tsocks, en version 1.5+ avec la résolution de nom forcée via le proxy.

Ninite, est un logiciel propriétaire pour windows qui fournit exactement ce service:
- tous les fichiers sont téléchargés depuis les serveurs officiels du créateur du logiciel, vérifiés, puis installés silencieusement avec les scripts de Ninite.
- le logiciel a une version gratuite pour les particuliers, et une version payante à destination des admins qui est 100% automatisée pour un parc.

À noter que pas mal de logiciels libres pour windows sont packagés par ninite, et qu’il semblerait qu’ils aient une version linux qui s’intègre avec Ubuntu et apt.

Vous avez tous bien deviné, ce sont les images que je ne visualisaient pas. Je m’en étais rendu compte, j’aurais du ajouter ce certificat plus tôt avant de me faire avoir…

Cela dit un title text plus descriptif aurait été un plus =)

Ya un "OpenScad", un "Firstboot" et "Cora" qui se baladent dans le texte, probablement des vestiges d’un brouillon non finalisé.

Les modérateurs sont autorisés à détruire ce commentaire une fois la correction effectuée =)

Elle est dispo et fonctionnelle. Je t’invites à utiliser l’arbre git kernel suivant:
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.11-wip-5

Du coup t’auras immédiatement les gains de 20°c (et plus d’autonomie) que certains ont pu observer sur leurs laptops…

Ce n’est pas parce que toi tu préfères des produits finis et mâchés par les distros que personne ici n’a envie de savoir qu’AMD a enfin autorisé la libération de ce code; attendu par pas mal de monde.

On parle pas d’un leak, on parle d’Open Source et de 3 ans de boulots libérés dans une patch bomb d’au moins 165 patchs. Donc rien à voir avec les "leaks" marketing des gadgets ou boites qui font du proprio.

Ce que je veux dire, c’est qu’il y a pas besoin de son, des impulsions suffisent (vibrations, décharges électriques, autres… ?), avec un système similaire au morse, mais avec un encodage spécifique aux coordonnées d’échecs.

Un simple récepteur radio sous-cutané (ou dans son slip, je sais pas si les contrôles de compétitions d’échecs demandent de se pencher tout nu et de tousser), avec un vibreur ou des mini-électrocutions, un encodage des mouvements basiques (ya pas beaucoup de bits d’information à transmettre) pourrait permettre cette "astuce".

Par contre il lui faut un complice dans la salle pour enregistrer les mouvements et les rentrer dans un logiciel de triche.

C’est une fonctionnalité de base de XMPP. Cf XEP 13.

En fait ce qui me gène en général dans ce journal, c’est que tout ce qui est décrit est faisable XMPP. Il suffirait juste de faire une mise à jour du client.
Après il y a peut-être d’autres fonctionnalités de Hangouts qui ne sont pas faisables aujourd’hui. Mais pour ça ils pourraient rajouter des extensions non standards (mais spécifiées), vu que le principe de base du protocole est d’être extensible.

Donc Greg KH* se tripote la nouille:
http://www.kroah.com/log/linux/year_in_my_life_2012.html

*Bon OK c’est un surhomme.