Ph Husson a écrit 2703 commentaires

[je m'la pete avec ma science que j'étale bien (surtout que j'ai appris ça récemment)]
10.0.xx.0/24 n'est PAS un réseau de classe C
cf http://fr.wikipedia.org/wiki/Classe_d'adresse_IP
Le premier octet d'une adresse IP de classe C commence toujours par la séquence de bits 110, il est donc compris entre 192 et 223. Un exemple d'adresse IP de classe C est : 192.168.1.34.
[/je m'la pete]
C'est une croyance populaire (même ma grand-mère le croit!) que de croire que /24 est synonyme de classe C, mais c'est faux en fait.

Coucou VP8 \o/

Juste pour les yeux
s/fixer/corriger/

En quoi ça s'oppose à ce qu'il dit ?
Les baux très courts signifient juste que tu dois dire souvent au serveur que t'es encore en vie, c'est tout ...
Sur FreeWifi les baux sont de l'ordre d'une minute (3 je crois), ça n'empeche pas de garder la même IP tant qu'on est connecté (et même en changeant de borne ! mais bon ça c'est une autre histoire.)

- Le support hardware sur les telephones/devices embarque est aussi inexistant, et mettre un arm a genoux quand t'as un decodeur hardware assis juste a cote, c'est un peu ballot vous trouvez pas?
nVidia Tegra2 (majorité des tablettes android haut de gamme) le gère, ainsi que les Qualcomm MSM7255/MSM7250A/MSM7260. Et pour TI et Samsung, c'est juste que je ne connais pas leur position, mais TI était dans la liste des supports à la fondation (?) webm.

Je doute que les devs android soient idiots :)
Mais je sais pas comment ils font pour forcer l'application de ces droits, si c'est au niveau du market, si les-dites fonctions sont accessibles que si on dit qu'on y accède (ce qui est plutôt simple à faire), ou autre.

Oui et non.
ll ne regarde pas quelles fonctions sont utilisées, c'est le dévelopeur qui remplit un fichier à part qui spécifie quelles fonctions il utilise.
Le GROS problème, c'est que les dévs y mettent à peu près tout ce qui leur sert pendant le dév, et donc on se retrouve avec des listes absolument énormes pour chaque soft. Si bien qu'au final plus personne ne regarde plus ça, vu que la plupart des applications, bien que légitimes, annoncent des trucs qui n'ont rien à voir.

Un jour faudra porter plainte pour pubilicité mensongère sur ce genre de connerie.

Maintenant ils n'ont plus de truc fermé en espace noyau, tout ce qui est propriétaire est en espace utilisateur, ce qui est presque un progrès si on compare à leur bordel sur x86 :p

On en avait parlé ici à une époque, en parlant du besoin de ces agents de temps de réponse le plus court possible et que pour ça il fallait surtout des bécanes à la fréquence maximale

Oh le beau lapsus! :p
Cette page c'est du grand n'importe quoi, le nokia N900 n'est pas une architecture à part entière à lui tout seul !
Il reste vrai qu'il y a énormément d'architectures ARM très différentes (même les timers ne sont pas standardisés !).
Enfin bon, les architectures puissantes actuelle c'est les TI Omap, Qualcomm Snapdragon, Samsung Hummingbird et nVidia Tegra, c'est déjà beaucoup plus réduit.

Sur le fpu ok, je m'attendais même à ce que le Cortex soit largement plus loin vu que c'est un modèle sans neon.
Pour le reste, j'ai fait des benchmarks de mon côté, et j'ai clairement pas les même résultats ...
J'ai pas fait énormement de benchmarks, mais déjà plus que le monsieur. Ceux que j'ai fait c'est calcul de sqrt(2) dans bc avec 20000 digits, différents tests d'accès mémoire (pour être plus précis, somme d'éléments d'un tableau d'entiers), aussi bien en pseudo-aléatoire qu'en séquentiel. (que je n'ai pas cherché à optimiser par vectorisation vu que je voulais éviter de tomber sur le fpu)

Il y a un nouvel (à peine un an) arrivant mAjeur dans le marché ARM: nVidia.
Et je pense que c'est en grande partie à cause d'eux que microsoft se met aussi à l'ARM.
nVidia était completement coincé depuis quelques temps: Sur les intels récent, pour avoir un bus pci-express 16x 2.0 toussa, et donc pouvoir mettre une carte graphique externe, il faut déjà viser des modèles "haut de gamme", à côté de ça, il y a eu la fusion ATI/AMD. Je parle même pas du marché des chipsets sur lequel nVidia a tout simplement disparu (c'est con, ils ont fait le seul chipset avec mixage audio hard à ma connaissance). Bref, nVidia a une marge de manoeuvre sur x86 franchement réduite.
Et il y a aussi un phénomène plutôt récent: toute la puissance de calcul migre vers les cartes graphiques, et le cpu ne servent pour autant dire plus à rien pour la plupart des utilisations.
nVidia voulant aussi jouer sur la table des petits (ie ordi bon marchés), la solution est simple.. se mettre à l'arm !
On avait vu depuis quelques mois nVidia mettre ses puces Tegra en place, largement en avance sur ses concurrents, avec la sortie d'un Cortex-A9 (qui apporte dual-core et out of order), ou plus anciennement le Tegra dans les Zune HD de Microsoft. Le Toshiba AC100 (smartbook Tegra2, bien qu'android ('fin officiellement)) est un précurseur de ce que nVidia prévoit. Ils ont en effet annoncé au CES qu'ils allaient investir avec cette plateforme la plupart des marchés: aussi bien les supercalculateurs (en effet, pas besoin d'un x86 sur puissant juste pour controler des cartes graphiques !), aux ordinateurs bas/moyen de gamme, grace à l'ARM Cortex-A15 et à leur SoC fait maison. Les seuls secteurs laissés libres à l'x86 seront le hardcore gaming (je sais pas si c'est le bon terme mais vous comprenez l'idée.), et les agents de bourse (qui peuvent pas paralléliser).
Pour donner un état des lieux de leur technologie actuelle, j'ai pu comparer un AC100 avec un netbook atom. Sur les différents benchmark que j'ai fait, l'ac100 est plus rapide que l'atom (sans prendre en compte le double coeur), aussi bien en terme de cpu que de gpu, pour une consommation ridiculement faible en comparaison. (plus de 5 heures d'autonomie sur une batterie 3 cellules quoi.)
Je vois deux issues possible à tout ça:
-Intel se bouge le cul, et on voit une nouvelle explosion des performances de l'x86 comme on l'a vu à l'occasion des Core2Duo
-ARM domine le marché
Dans tous les cas, ça donnera un coup de boost à ce secteur des processeurs d'ordinateur qui s'était essouflé depuisi que AMD n'arrive plus à grand chose.

Quel rapport ? oO

Fournir de la doc et fournir un code source sont deux choses extrêmement différentes, (cf intel qui abandonne le développement de certains drivers, et personne ne peut reprendre parce que pas de doc.)

Depuis android, Qualcomm publie la quasi totalité de ses sources liées à linux....
Sur leur puces récentes, à ma connaissance tout ce qu'il manque pour faire une distrib linux libre, c'est le driver 3D et l'interface radio (GSM/UMTS j'entends. le GPS est fourni en libre)
Et tout ça est disponible sur codeaurora.org

Pourquoi pas verouillage fin, tout simplement ?

euh ... là le thread ci parle des dégroupés, +2€ sur 30€, ça fait jamais 20% d'augmentation.
Si tu parle des non dégroupés, y a pas de raison officielle, mais bon ça doit juste être une conjonction de facteurs, utilisateurs qui bouffent toujours plus de bande passante qui coùte cher, hausse de la TVA, hausse des frais généraux.

Vous avez des proches qui ont reçu des mails ?
À federez (un regroupement d'assoces qui gèrent le réseau informatique des résidence des grandes écoles), de nombreuses assoces ont déjà reçu de tels messages.
Forcément ils ont un grand nombre d'adhérents, donc ils s'en prennent plein dans la gueule.

Ouais, EDF augmente de 1% tous les 6 mois, c'est carrement mieux.

La baisse de la TVA n'était pas là juste pour faire plaisir aux FAI hein
C'était en compensation de la taxe COSIP à destination des ayants droits.
Donc non, lors de la baisse de la tva, free n'y a rien gagné.

Oui et ?
Ce que je veux dire c'est que le dégroupage partiel est moins cher que le dégroupage total, alors que l'adsl nu est aussi cher que le non dégroupé avec FT

Ouaip, même prix pour l'offre ADSL Only.
Ça parait idiot par rapport au dégroupage total, mais bon.

Sur mplayer j'ai aussi le problème, mais ça n'a rien à voir avec le cpu, c'est "juste" que les codecs marchent très mal sans cache (ce que je ne m'explique pas, mais passons.).
Essaye de lire ce que t'es entrain d'enregistrer, tu seras fixé pour savoir si c'est effectivement un problème de CPU, mais les chaines débit "normal" MPEG2 devraient largement passer sur ta bécanne ...

C'est vrai que mon approximation me fait un peu peur en y repensant ... Avec une fréquence qui augmente on a l'effet de peau qui va augmenter la résistance des fils, donc réduire l'effet du CPL ....
Après quand je disais aucune résistance, je pensais à "pas de dipole éléctrique relié entre la phase et le neutre", content ?:p




2)) Le 1V du cpl ne sert qu'a transmettre l'information, donc son intensité peut se permettre d'être assez faible (et je pense que le boitier cpl présente une résistance extrêmement importante en entrée pour son canal info).

Le 220v ne sert pas à transmettre de l'information mais uniquement de l'énergie, aux appareils branchés, donc l'intensité utilisée est conditionné par les appareils branchés.

Si tu as juste ton adaptateur cpl de branché, voui on peut considérer que les deux intensité (alim cpl en 220v et envoi info) tendent vers 0.

Mais si tu utilise ton réseau, ce n'est plus du tout vrai.

Bah oui... c'est bien ce que je dis
J'ai jamais dit que ça tendait vers 0, bien au contraire, si ça valait 0, le champ sortant serait nul -_-'
C'est vrai que mon dernier message après relecture est tout sauf clair. Ce que je voulais dire avec ça c'est justement qu'on ne peut pas séparer la conso du 220 et du CPL, et que le cpl ne peut pas avoir de consommation tendant vers 0 si on a des charges.