il manque une précision importante dans tout ça, c'est comment le GPS transmet sa position en temps réel au serveur de Ford. Soit la bagnole a sa propre puce 3G (et là, il faut quand même arrêter le délire), soit ça passe par une application sur le téléphone du conducteur.
Il y a des centaines de manières de le faire… le réseau GSM, 3G, CB, les données collectée sagement en attendant de revenir au garage, les données transmise à n'importe quelle voiture voisine capable de les retransmettre à nouveau… Soulever un problème, avancer deux hypothèses les réfuter grossièrement et en conclure que le problème n'existe pas c'est léger.
De toutes manières, je suis persuadé depuis quelques années que d'essayer de contrôler les données personnelles et les traces qu'on laisse un peu partout, c'est comme de militer contre la gravité ou contre le capitalisme. C'est là qu'on le veuille ou non, et on ne peut que s'épuiser en vain à lutter. Attention, accepter la gravité, ça ne revient pas à accepter de se casser la gueule à tous les coins de rue : le fait de savoir que ça existe et que c'est ineluctable permet juste de vivre normalement sans trop d'accidents.
Heureusement que des Hommes ont milité contre la gravité et ont inventé l'avion, ils ont milité contre l'esclavage et ils ont gagné, ils ont milité contre une maladie et ont trouvé un médicament. Et il y a des gens qui leur on dit « aucun objet plus lourd que l'air ne peut voler », « il y a des hommes qui sont nés pour servir, d'autre pour êtres servis », « si on meurs de maladie c'est le dessein de dieu, nous n'y pouvons rien ».
Qu'on le veuille où non, aujourd'hui quelques personnes ont bien trop de pouvoir. Et que tu le veuille où non, c'est possible principalement grâce à des thèse défaitistes comme les tiennes. Ces gens là n'ont que le pouvoir qu'on leur donne. À moins que tu ne pense que ceux qui défendaient l'esclavage avaient raison ?
De toutes manières, il est probable que trop de données tuent les données.
C'est probable oui, et faux. Toutes les données sont exploitable. Une équipe japonaise a réussi à identifier un homme avec un taux de certitudes tout à fait honorable simplement en disposant des capteurs un siège de voiture. Des données aussi triviale que l'empreinte d'un cul sur un siège de voiture peuvent permettre d'identifier quelqu'un.
Le volume des données, c'est rien. Facebook fait de la reconnaissance faciale sur les centaines de milliers (millions ?) de photo. Google indexe grosso modo tout le web et permet de donner une réponse à n'importe quel mon clé en quelques millièmes de secondes.
Tu as une image très étriquée du problème à mon sens. On ne parle pas de la publicité ciblée, c'est rien la publicité ciblée. Ces machines avec assez de données peuvent percevoir le zeitgeist en temps réel. Elles permettent de connaitre n'importe quoi sur n'importe qui, pas seulement les données qui ont explicitement été transmises, mais aussi les données inférées.
Que peut ont faire de ses données ? Qu'en aurait fait la stasi ? Les nazis ? La monarchie française avant d'être raccourcie ? Sera-t-il encore possible de se révolter si une machine peut voir ton mécontentement avant même que tu en ais conscience ?
Il y a des choses pour lesquels les ordinateurs sont très mauvais. Même des choses « simple », comme être intelligent au sens où un humain l'entend. Mais pour traiter de grandes quantités de données ils sont imbattables.
Méa culpa, je pensais qu'il l'était. Ça explique encore mieux pourquoi c'est plus lent avec le code x86.
On parlait du fait qu'ils s'étaient cassé la gueule avec l'itanum, c'est pas qu'un problème hardware, mais aussi économique. Une partie de l'explication réside dans le fait que les industriels qui sont coincés sur x86 à cause logiciel privateur n'ont pas eu intérêt à passer à l'itanium car il aurait ralenti leur logiciels. Contrairement aux nouvelles générations x86 et amd64.
Et tu crois franchement qu'une seul des ses distributions va décider de faire un port pour ton cpu tout beau tout neuf ?! Quand au C hyper portable, je rappelle qu'il peut y avoir des problèmes rien qu'entre les versions 32 et 64 bits sous x86.
Mon CPU ? De quoi tu parle ? Je ne comprend pas cette agressivité (à moins que ce ne soit du mépris ?).
Si demain un intel ou AMD, ou nvidia sort un CPU patator, s'il en vend… alors oui, bien sûr que les distro feront l'effort. La boite en question payera pour ça même, parce que personne n’achète une machine sur laquelle ne tourne aucun système d'exploitation.
Quand au C hyper portable
Une petite aide à la lecture :
Parce que du code C correct est hyper portable
Je ne devrais pas m'abaisser à répondre… Citer l'autre aussi grossièrement c'est grotesque.
Tu n'as à alors rien compris au supposé avantage du vliw sur le superscalaire. Le but était de sauver du silicium pour mettre plus d'unité de calcul dans le même espace (ou budget de portes logiques). Si tu perds encore plus de place pour mettre du cache, c'est juste un gros failed.
Accuser l'autre de ne rien comprendre n'est pas un argument. Je suis juste pas convaincu par les arguments qualitatif. « Plus de ça, moins de ci, ergo : big fail » n'est pas un raisonnement valide.
Considérant une toute nouvelle architecture, il faut la considérer dans son ensemble. Tu peux pas juste dire « celle là a besoin de plus de cache, ça va à l'encontre du but recherché, donc c'est de la merde ». Il faut aussi considérer le fait certaines parties seront plus simple et permettrons d'économiser, que l’accélération ne se fera pas au même endroit. (des registres à gogo avec avec les instructions qui arrivent 15 par 15 ça comptent pas ?). Non… j'dois être trop con.
À bon entendeur, et je tacherais de ne plus trahir ma signature à l'avenir.
Tu plaisantes ? Tu connais beaucoup de distribution linux qui supporte "plein" de version de cpu ?
[plein de distro linux qui supportent plein de versions de cpu]
Parce que du code C correct est hyper portable. C'est facile à faire. La compatibilité binaire c'est un problème de logiciel privateur.
Je vais préciser… Aujourd'hui les amd64 extraient tout le parallélisme entre les instructions à la volée (même si le compilo aide en séparant ce qui peut l'être).
Une grande partie de ce boulot pourrait être fait en statique, une fois pour toute. La logique c'est « je ne sais pas quelles questions les étudiants vont me poser pendant le cours… donc je vais y aller les mains dans les poches ». Il s'agit juste de faire la part des choses entre ce qui peut être fait statiquement et le reste. Parce que faire dynamiquement un truc qui peut l'être avant, c'est stupide.
Après, il y a aussi le problème portabilité des performances entre les processeurs compatibles. Pour ça il faut juste recompiler ce qui a besoin de l'être.
Parce que du code C correct est hyper portable. C'est facile à faire. La compatibilité binaire c'est un problème de logiciel privateur.
"Avec quel genre de code « normal » on a besoin de performances ?"
compilateur, base de donné, serveur, interface graphique, navigateur internet….
On doit pas avoir la même définition de « besoin de performances », ni de « code « normal » ».
- compilateur : des perfs pour quoi faire ?
- base de donnée : c'est surtout une question d'architecture logicielle
- serveur : idem
- navigateur internet… le truc qui doit juste télécharger quelques kilos et les afficher ? S'il est lent c'est qu'il a un problème d'architecture logicielle. Un meilleur compilo n'y changerait pas grand chose. Et pour afficher les images, ce sont des algo « scientifiques hyper réguliers » super parallelisables.
Le compilo d'Itanium prouve que c'est faux. De plus, pour avoir de bonnes perf, l'itanium a besoin d'un cache code énorme au contraire du x86.
Le mauvais support d'une technologie qui s'est cassé la gueule ne prouve pas grand chose, à part que les devs ne sont pas stupide. Pour l'histoire du cache, ce n'est pas un argument, juste un fait. De plus, l'itanium à un nom qui commence par un i, contrairement à l'x86.
d'un processeur a l'autre, on perd la compatibilité binaire.
Ça c'est un problème du logiciel privateur, pas libre.
les compilateurs fonctionnent bien que pour du code scientifique très régulier, pas pour du code "normal"
Avec quel genre de code « normal » on a besoin de performances ?
c'est la raison principale pour laquelle l'Itanium (qui est une sorte de VLIW) s'est planté en beauté..
L'autre hypothèse c'est que c'était la première génération compatible *86 à ne pas offrir de performance supérieure à la génération précédente (la faute à un simulateur plus lourd et une fréquence de travail plus basse). Encore un problème du logiciel privateur…
Aujourd'hui, les processeurs sont obligés d'extraire le parallélisme entre les instructions, dynamiquement alors que ça pourrait mieux être fait de manière statique. Et que les transistors qui font ces calculs pourraient surement être utilisés plus utilement.
Une carte graphique c'est pas un manycore, c'est une architecture SIMD, Simple Instruction Multiple Data. Très efficace pour traiter beaucoup de données mais toutes exactement de la même manière. C'est à dire sans même d’exécution conditionnelle.
Le MPPA est un MIMD. Il peut traiter plusieurs données différentes en même temps, avec plusieurs traitement différents, plusieurs programmes différent même il me semble…
les processeurs type Xeon sont « moyennement » bons partout.
Non… Pour des algorithmes séquentiels on a pas mieux (à part le processeur ad-hoc).
La bonne solution c'est le secure boot: le bios vérifie le boot qui lui vérifie le initrd qui vérifie le reste. Mais je ne sais pas si c'est facile à mettre en place.
Les attaques contre le BIOS c'est pas ce qui manque… Je pense qu'un début de solution c'est de ne pas avoir d'x86.
Mais bon, après ça dépend de quoi l'on souhaite de protéger.
Tu as btrfs qui fait des snapshot à chaud, et inscriptibles, et HammerFS qui fait des snapshot en continue, il supprime jamais rien, avec une granularité de l'ordre de la seconde si ma mémoire est bonne.
On parle beaucoup de la distorsion introduite par l'amplification et la pré-amplification, mais elle est plusieurs ordres de grandeurs en dessous de celle des enceintes.
On peut se servir d'une grenade comme d'un presse papier aussi. Pour peu qu'elle soit utilisée par un médecin pour garder les dossiers de ses patients, les grenades sont bonnes pour la santé.
[^] # Re: Mouai
Posté par Zylabon . En réponse au journal Vie privée ? Connais pas. Évalué à 10.
Il y a des centaines de manières de le faire… le réseau GSM, 3G, CB, les données collectée sagement en attendant de revenir au garage, les données transmise à n'importe quelle voiture voisine capable de les retransmettre à nouveau… Soulever un problème, avancer deux hypothèses les réfuter grossièrement et en conclure que le problème n'existe pas c'est léger.
Heureusement que des Hommes ont milité contre la gravité et ont inventé l'avion, ils ont milité contre l'esclavage et ils ont gagné, ils ont milité contre une maladie et ont trouvé un médicament. Et il y a des gens qui leur on dit « aucun objet plus lourd que l'air ne peut voler », « il y a des hommes qui sont nés pour servir, d'autre pour êtres servis », « si on meurs de maladie c'est le dessein de dieu, nous n'y pouvons rien ».
Qu'on le veuille où non, aujourd'hui quelques personnes ont bien trop de pouvoir. Et que tu le veuille où non, c'est possible principalement grâce à des thèse défaitistes comme les tiennes. Ces gens là n'ont que le pouvoir qu'on leur donne. À moins que tu ne pense que ceux qui défendaient l'esclavage avaient raison ?
C'est probable oui, et faux. Toutes les données sont exploitable. Une équipe japonaise a réussi à identifier un homme avec un taux de certitudes tout à fait honorable simplement en disposant des capteurs un siège de voiture. Des données aussi triviale que l'empreinte d'un cul sur un siège de voiture peuvent permettre d'identifier quelqu'un.
Le volume des données, c'est rien. Facebook fait de la reconnaissance faciale sur les centaines de milliers (millions ?) de photo. Google indexe grosso modo tout le web et permet de donner une réponse à n'importe quel mon clé en quelques millièmes de secondes.
Tu as une image très étriquée du problème à mon sens. On ne parle pas de la publicité ciblée, c'est rien la publicité ciblée. Ces machines avec assez de données peuvent percevoir le zeitgeist en temps réel. Elles permettent de connaitre n'importe quoi sur n'importe qui, pas seulement les données qui ont explicitement été transmises, mais aussi les données inférées.
Que peut ont faire de ses données ? Qu'en aurait fait la stasi ? Les nazis ? La monarchie française avant d'être raccourcie ? Sera-t-il encore possible de se révolter si une machine peut voir ton mécontentement avant même que tu en ais conscience ?
Il y a des choses pour lesquels les ordinateurs sont très mauvais. Même des choses « simple », comme être intelligent au sens où un humain l'entend. Mais pour traiter de grandes quantités de données ils sont imbattables.
Please do not feed the trolls
[^] # Re: Et les compilateurs?
Posté par Zylabon . En réponse à la dépêche Kalray un processeur massivement parallèle très impressionnant : Qu’il est loin le temps de mon ZX81. Évalué à 2.
Méa culpa, je pensais qu'il l'était. Ça explique encore mieux pourquoi c'est plus lent avec le code x86.
On parlait du fait qu'ils s'étaient cassé la gueule avec l'itanum, c'est pas qu'un problème hardware, mais aussi économique. Une partie de l'explication réside dans le fait que les industriels qui sont coincés sur x86 à cause logiciel privateur n'ont pas eu intérêt à passer à l'itanium car il aurait ralenti leur logiciels. Contrairement aux nouvelles générations x86 et amd64.
Please do not feed the trolls
[^] # Re: Et les compilateurs?
Posté par Zylabon . En réponse à la dépêche Kalray un processeur massivement parallèle très impressionnant : Qu’il est loin le temps de mon ZX81. Évalué à 2.
Mon CPU ? De quoi tu parle ? Je ne comprend pas cette agressivité (à moins que ce ne soit du mépris ?).
Si demain un intel ou AMD, ou nvidia sort un CPU patator, s'il en vend… alors oui, bien sûr que les distro feront l'effort. La boite en question payera pour ça même, parce que personne n’achète une machine sur laquelle ne tourne aucun système d'exploitation.
Une petite aide à la lecture :
Je ne devrais pas m'abaisser à répondre… Citer l'autre aussi grossièrement c'est grotesque.
Accuser l'autre de ne rien comprendre n'est pas un argument. Je suis juste pas convaincu par les arguments qualitatif. « Plus de ça, moins de ci, ergo : big fail » n'est pas un raisonnement valide.
Considérant une toute nouvelle architecture, il faut la considérer dans son ensemble. Tu peux pas juste dire « celle là a besoin de plus de cache, ça va à l'encontre du but recherché, donc c'est de la merde ». Il faut aussi considérer le fait certaines parties seront plus simple et permettrons d'économiser, que l’accélération ne se fera pas au même endroit. (des registres à gogo avec avec les instructions qui arrivent 15 par 15 ça comptent pas ?). Non… j'dois être trop con.
À bon entendeur, et je tacherais de ne plus trahir ma signature à l'avenir.
Please do not feed the trolls
[^] # Re: Et les compilateurs?
Posté par Zylabon . En réponse à la dépêche Kalray un processeur massivement parallèle très impressionnant : Qu’il est loin le temps de mon ZX81. Évalué à 0.
Petite aide à la lecture :
Please do not feed the trolls
[^] # Re: Et les compilateurs?
Posté par Zylabon . En réponse à la dépêche Kalray un processeur massivement parallèle très impressionnant : Qu’il est loin le temps de mon ZX81. Évalué à 3. Dernière modification le 09 janvier 2014 à 13:53.
Je vais préciser… Aujourd'hui les amd64 extraient tout le parallélisme entre les instructions à la volée (même si le compilo aide en séparant ce qui peut l'être).
Une grande partie de ce boulot pourrait être fait en statique, une fois pour toute. La logique c'est « je ne sais pas quelles questions les étudiants vont me poser pendant le cours… donc je vais y aller les mains dans les poches ». Il s'agit juste de faire la part des choses entre ce qui peut être fait statiquement et le reste. Parce que faire dynamiquement un truc qui peut l'être avant, c'est stupide.
Après, il y a aussi le problème portabilité des performances entre les processeurs compatibles. Pour ça il faut juste recompiler ce qui a besoin de l'être.
Please do not feed the trolls
[^] # Re: Et les compilateurs?
Posté par Zylabon . En réponse à la dépêche Kalray un processeur massivement parallèle très impressionnant : Qu’il est loin le temps de mon ZX81. Évalué à 2.
Oui. cf http://distrowatch.com :
Et accessoirement…
Parce que du code C correct est hyper portable. C'est facile à faire. La compatibilité binaire c'est un problème de logiciel privateur.
On doit pas avoir la même définition de « besoin de performances », ni de « code « normal » ».
- compilateur : des perfs pour quoi faire ?
- base de donnée : c'est surtout une question d'architecture logicielle
- serveur : idem
- navigateur internet… le truc qui doit juste télécharger quelques kilos et les afficher ? S'il est lent c'est qu'il a un problème d'architecture logicielle. Un meilleur compilo n'y changerait pas grand chose. Et pour afficher les images, ce sont des algo « scientifiques hyper réguliers » super parallelisables.
Le mauvais support d'une technologie qui s'est cassé la gueule ne prouve pas grand chose, à part que les devs ne sont pas stupide. Pour l'histoire du cache, ce n'est pas un argument, juste un fait. De plus, l'itanium à un nom qui commence par un i, contrairement à l'x86.
Please do not feed the trolls
[^] # Re: Et les compilateurs?
Posté par Zylabon . En réponse à la dépêche Kalray un processeur massivement parallèle très impressionnant : Qu’il est loin le temps de mon ZX81. Évalué à 1.
Ça c'est un problème du logiciel privateur, pas libre.
Avec quel genre de code « normal » on a besoin de performances ?
L'autre hypothèse c'est que c'était la première génération compatible *86 à ne pas offrir de performance supérieure à la génération précédente (la faute à un simulateur plus lourd et une fréquence de travail plus basse). Encore un problème du logiciel privateur…
Aujourd'hui, les processeurs sont obligés d'extraire le parallélisme entre les instructions, dynamiquement alors que ça pourrait mieux être fait de manière statique. Et que les transistors qui font ces calculs pourraient surement être utilisés plus utilement.
Please do not feed the trolls
[^] # Re: et sinon ?
Posté par Zylabon . En réponse à la dépêche Kalray un processeur massivement parallèle très impressionnant : Qu’il est loin le temps de mon ZX81. Évalué à 2.
Les driver Linux existent (je sais même pas si yen a d'autres).
Et il me semble qu'il y a un petit linux hyper modifié qui tourne dessus aussi. (pour faire les IO, l'ordonnancement… tout ça).
Please do not feed the trolls
[^] # Re: Et les cartes graphiques ?
Posté par Zylabon . En réponse à la dépêche Kalray un processeur massivement parallèle très impressionnant : Qu’il est loin le temps de mon ZX81. Évalué à 10.
Une carte graphique c'est pas un manycore, c'est une architecture SIMD, Simple Instruction Multiple Data. Très efficace pour traiter beaucoup de données mais toutes exactement de la même manière. C'est à dire sans même d’exécution conditionnelle.
Le MPPA est un MIMD. Il peut traiter plusieurs données différentes en même temps, avec plusieurs traitement différents, plusieurs programmes différent même il me semble…
Non… Pour des algorithmes séquentiels on a pas mieux (à part le processeur ad-hoc).
Please do not feed the trolls
[^] # Re: avec ssh
Posté par Zylabon . En réponse au message Proxy SOCKS5: connexion impossible. Évalué à 2.
Le chiffrement c'est rien du tout dans le temps total. Ça se compte en micro secondes.
La seule chose qui pourra te permettre de gagner c'est de choisir un proxy près de toi (au moins le même continent).
Please do not feed the trolls
# avec ssh
Posté par Zylabon . En réponse au message Proxy SOCKS5: connexion impossible. Évalué à 2.
Avec SOCKS5 oui, et ssh -D met en place un serveur socks5 sauf erreur de ma part.
Please do not feed the trolls
[^] # Re: pas suffisant
Posté par Zylabon . En réponse au message Checksum de la partition /boot. Évalué à 2.
Les attaques contre le BIOS c'est pas ce qui manque… Je pense qu'un début de solution c'est de ne pas avoir d'x86.
Mais bon, après ça dépend de quoi l'on souhaite de protéger.
Please do not feed the trolls
[^] # Re: Serieux?
Posté par Zylabon . En réponse au journal Badbios vous a plu? Vous allez aimer le catalogue NSA. Évalué à 8.
Venants de bidasses je trouve ça pas mal, il n'y a même pas de fautes.
Please do not feed the trolls
# Pourquoi ?
Posté par Zylabon . En réponse au message Définition d'un compte mail sans nom de domaine. Évalué à 1.
Il y a des sous domaines gratuits, par exemple chez no-ip.org, ou plein d'autres.
Pour la question je ne connais pas la réponse.
Please do not feed the trolls
[^] # Re: Idée alakon
Posté par Zylabon . En réponse au message filesystem, traçabilité des modifications, restauration après suppression. Évalué à 3.
Tu as btrfs qui fait des snapshot à chaud, et inscriptibles, et HammerFS qui fait des snapshot en continue, il supprime jamais rien, avec une granularité de l'ordre de la seconde si ma mémoire est bonne.
Please do not feed the trolls
[^] # Re: C'est pas pour gâcher l'esprit de Noël, mais...
Posté par Zylabon . En réponse au journal Alan Turing gracié.. Évalué à 10.
Il a été gracié, pas innocenté…
Please do not feed the trolls
[^] # Re: L'escroquerie audiophile
Posté par Zylabon . En réponse à la dépêche NwAvGuy O2 : l’amplificateur casque sous licence Creative Common. Évalué à 5.
+1
On parle beaucoup de la distorsion introduite par l'amplification et la pré-amplification, mais elle est plusieurs ordres de grandeurs en dessous de celle des enceintes.
Please do not feed the trolls
# Petite correction
Posté par Zylabon . En réponse au message Libération de code source. Évalué à 5.
(ou même simplement le rendre disponible sur simple demande via e-mail ou autre)
Please do not feed the trolls
# Pourquoi il faut un gestionnaire de fenêtre ?
Posté par Zylabon . En réponse au journal Steam OS version facile. Évalué à 7.
Lancer un X tout nu c'est pas bien ?
Please do not feed the trolls
[^] # Re: Et l'État dira :
Posté par Zylabon . En réponse au journal Une pétition contre le Patriot Act à la française (art. 20 (anc. 13) de la PM). Évalué à 9.
Les citations bibliques c'est un peu un corpus de mèmes pré-internet.
Please do not feed the trolls
[^] # Re: le jour ou on blâmera le marteau
Posté par Zylabon . En réponse au journal Un bug inhumain. Évalué à 10.
On peut se servir d'une grenade comme d'un presse papier aussi. Pour peu qu'elle soit utilisée par un médecin pour garder les dossiers de ses patients, les grenades sont bonnes pour la santé.
Please do not feed the trolls
[^] # Re: Mo
Posté par Zylabon . En réponse au journal OpenWRT et TP-Link TL-WR710N. Évalué à 2.
J'ajouterais que dans le cas d'un routeur, plus de mémoire -> buffer plus gros -> plus de latence.
Qui n'a jamais vu la latence crever le plafond sur une box à cause d'une seule connexion un peu « chargée » ?
Please do not feed the trolls
[^] # Re: Mo
Posté par Zylabon . En réponse au journal OpenWRT et TP-Link TL-WR710N. Évalué à 3.
Pourquoi mettre 1Go alors que 32 Mo suffisent ?
Please do not feed the trolls
[^] # Re: Finalement
Posté par Zylabon . En réponse au journal Bookmark le monde. Évalué à 2.
Encore un qui confond la gauche et le PS…
Please do not feed the trolls
# C'est bon.
Posté par Zylabon . En réponse au message envie de faire du C++11 au sein d'une dream-team, dans cadre idyllique, tout en étant payé ?. Évalué à 10.
Le charset est correct.
Please do not feed the trolls