M a écrit 2988 commentaires

C'est bien beau toute ces nouveautés, mais est-ce que les drivers suivent [1] ?

Ou alors ces nouveautés sont réservés que pour les dernières cartes graphique (ou pilote bien maintenue).


[1] par exemple qui supporte à ce jour DRI2.

Voilà, l'information est bien là, mais les vidéos sont inaudibles. Dans le dernier article de Phoronix sur cet évènement ( http://www.phoronix.com/scan.php?page=news_item&px=NzA2N(...) ), il est dit que l'on peut facilement enlever le bruit de la bande son en utilisant Audacity.
Ils ne savent pas non plus filmer : on voit pas les transparents (au moins dans certaines video).
Dans ce cas autant avoir que la bande son...
Mais bon espérons que les slides seront diffusé à coté...

Refuse ces conditions, ne signe pas cet avenant et continu d'utiliser ta carte comme d'habitude.
Tiens ça me rappel que j'ai toujours pas renvoyé l'accusé de reception de ma nouvelle CB (et des nouvelles conditions générales). Pourtant ça fait plus de 6 mois qu'elle marche sans soucis...

Vive les vérifs au niveau des banques...

Pour ce qui concerne le détail des améliorations, cette nouvelle version apporte :

* La gestion du recto-verso manuel
* La gestion du recto-verso inversé
* Une meilleure gestion des couleurs

C'est vraiment au driver de faire tout ça ?
Cups n'est pas capable de gérer ça de manière générique ?

Par contre il y a un truc absolument génial sur l'x86, c'est la gestion de la mémoire. C'est une tuerie : les 4 ring, la segmentation, la gestion de la mémoire paginée, bref le 386, c'est génialement pensé.

Oui, mais bon est-ce réellement utilisé ?
Déja la segmentation on dirait pas.
Qui utilise les 4 rings ? Linux en utilise 2, Windows 3 ?

Je préfère largement une bête table mmu avec un mode user/superviseur.

PS : ce qui est une tuerie (un vrai merdier), c'est les differents mode du x86 : real mode, unreal mode, protected mode, virtual mode, ...

C'est quoi le rapport avec Intel ?
La majeur partie des evolutions ont été fait par ARM pas intel...

Analysons http://shootout.alioth.debian.org/u32q/benchmark.php?test=th(...)


1.0 Haskell GHC #2 8.88
1.1 Haskell GHC 10.84
1.8 Mozart/Oz 15.91
3.3 Erlang HiPE 29.14
4.0 Smalltalk VisualWorks #2 35.87
7.8 Scheme PLT 69.19
14 Scala 122
16 Pascal Free Pascal 124.66
17 Lisaac 130.07
18 C++ GNU g++ #2 148.56

[...]
Le meilleur, Haskell, torche en 9s

Mais il n'utilise qu'un seul core [1], tout comme Mozart, Smalltalk et Scheme.

Mon petit doit me dit que ce test crée plein de thread qui ne font quasiment rien. Du coup ce test test la rapidité de création de thread, et les implémentations purement userspace gagne haut la main car il n'y a pas tout l'overhead kernel...

Encore une fois les micro bench sont a prendre avec des pincettes...

[1]

x Program & Logs CPU secs Memory KB Size B Elapsed secs ~ CPU Load
1.0 Haskell GHC #2 8.88 2,872 260 8.89 0% 0% 5% 92%
1.1 Haskell GHC 10.84 4,944 304 9.93 52% 49% 0% 0%
1.8 Mozart/Oz 15.91 4,356 340 15.91 0% 0% 0% 100%
3.3 Erlang HiPE 29.14 6,456 273 29.14 61% 0% 37% 11%
4.0 Smalltalk VisualWorks #2 35.87 13,088 566 35.86 0% 0% 100% 0%
7.8 Scheme PLT 69.19 24,412 262 69.19 0% 0% 0% 100%

Ce qui est bien je trouve avec le multi-coeur, c'est que la limite de performance se retrouve côté algorithmique, bref, du côté du programmeur : la limite physique devient de plus en plus loin, et les perfs "pures" des langages également.
Et pourtant les codec vidéo qui consomme beaucoup (genre h264 sur un flux HD) sont toujours développé en c/c++ avec une parallélisation à la main...

On sais tous que le x86 a gagné grace à l'argent d'intel et non pour ses propriétés intrinsèques.
Mais aussi parce qu'il etait retro-compatible :
les personnes ayant acheté des logiciels proprios, ayant développé du code optimisé en assembleur, ... pouvait toujours le faire tourné sur les nouveaux cpu sans rien acheté de nouveau ni revalider leur code.

PS : du coté de arm [1] ca commence aussi à devenir le bordel :
il y a le mode 32 bits classiques, le mode thumb (instruction réduite tenant sur 16 bits), le mode thumb2 (ou les instructions sont de taille variable 16 ou 32 bits), et toutes les instructions dsp, SIMD qui ont été ajouté au fil des nouvelles versions...


[1] http://en.wikipedia.org/wiki/ARM_architecture

Ou un truc qui gére de manière potable les fichier pdf avec du vectoriel (genre les plans de la ratp) :
- evince et kpdf cherche a rendre tout le document : il mette des plombes à se charger et bouffe plein de mémoire.
- xpdf marche pas trop mal, bien qu'il pourrait commencé a
à précalculer autour de la zone de visualisation.

Et puis il y a les pdf avec formulaire qui ne sont pas forcement bien supporté...

gv ne lit pas tout les pdf : il lit surtout les ps.

Et on ne peut être sûr d'un logiciel que si l'on a accès au code source.
Pas du tout !!!!

Tu peux avoir le code source, et la version binaire de ta distrib a été patché [1].
Les lib externes (libc, lib graphique, ...) ont des failles/backdoor.
Le compilo insert des backdoor dans le code compilé.
L'os a des backdoors.
Le cpu, bios, périphérique ayant accès à la mémoire ont des backdoor.

Il faut donc t'assurer que toute la chaîne est propre. Déja pour le hardware c'est mort.
Il te faut auditer toute le soft qui tourne sur ton pc.
Admettons que les auteurs de soft sérieux l'ont fait et que leur serveur n'ont pas été hacké. De même ta distro est sérieuse et n'a pas ajouté de backdoor.
Comment peut tu être sur que ce que tu télécharge c'est la bonne version ?


[1] C'est encore plus simple si tu as rajouter des repos non officiel pour avoir des backport, jeux, ...

La situation s'améliore grandement ces temps-ci :
Y a des choses de nouvelles depuis 6 mois ?

http://cr.yp.to/djbdns/ipv6mess.html peut te donner quelques réponses

Mouais tu sais même sur les jeux fermé il existe
- des soluces (qui explique tout ce qu'il faut faire)
- des simulateurs (qui permette d'optimiser son comportement fasse à l'AI/autre joueur).

Il ne faut pas sous-estimer la puissance de reverse engineering des gamers.

Sinon il est toujours possible de faire du code libre qui est configurer par des fichier de conf/script qui n'ont pas besoin d'être diffusé : on diffuse qu'une version d'exemple.

C'est pareil pour l'eeepc, ca fait plusieurs semaines qu'android tourne dessus : http://virtuallyshocking.com/2008/12/20/building-android-for(...)

Je suis à fond pour le libre mais :

Driver inmaintenable, qui n'a pas de 3D, etc. Et la situation n'a pas changée depuis des années.
Il est maintenu par nvidia et le driver xf86-video-radeonhd ne semble pas avoir non plus la 3D.

Le driver NV est si mauvais, qu'il y a le driver nouveau fait sans le support de NVidia.
Pourtant toutes les distribs proposent encore le driver NV et pas le driver Nouveau. Et le driver nouveau a déjà quelques années devant lui (au moins 2 ans).
Quand est ce que l'on aura une version utilisable ?

Les specs sont très importantes pour pouvoir exploiter à fond le matériel (et à plus long terme), mais pour l'utilisateur final c'est pas ce qui compte le plus.

Il ne veut pas coder un driver pour sa carte graphique (ou attendre quelques années avant de pouvoir l'utiliser), il veut une carte fonctionnelle immédiatement qui lui offre la plus grosses parties des fonctionnalités de sa carte. C'est à dire pour une carte récente un driver X accéléré, de l'opengl performant, un support xv et éventuellement le support du décodage des video h264, ...

Or j'ai l'impression qu'a ce niveau la c'est nvidia qui sort du lot : oui ils ont un driver proprio (quelque fois buggé/bridé), mais qui a l'avantage d'offrir rapidement toutes les fonctionnalité offerte par leur carte.

Comment ça, on est encore Vendredi ?

eureusement que dans le monde UNIX, on gère le temps en comptant les secondes depuis le 1er janvier 1970... comme ça, les changement d'années sont complètement anodins.
Sauf que sous UNIX beaucoup de timestamp se base sur ce temps depuis le 1er janvier 1970 (CLOCK_REALTIME).
Or cette horloge peut être amenée à faire des sauts si l'utilisateur change la date, mais pas mal d'appli gère très mal les voyages dans le temps (ou alors ça oblige à avoir un code assez compliqué)...
Idem quand on sort d'une mise en veille, les applis font un saut brutal dans le futur.

Posix définit bien une horloge monotone (CLOCK_MONOTONIC) (souvent le temps depuis le boot), mais peu d'API permette de l'utiliser (par exemple les timestamp clavier du noyau Linux sont basé sur la clock realtime)....


PS : oui ntp est censé éviter les changements brutaux d'horloge, mais par exemple dans le cas d'un système embarqué sans rtc (ie l'horloge n'est pas conservée dans le système est éteint), tous un tas d'applis seront lancées avant que la date réelle soit mise à jour.

Il y a des mini chaines numérique (genre [1]) qui sont capable de lire depuis une source audio externe, depuis une sd-card, depuis du mass-storage usb (donc un gros disque dur), depuis la fm et même pour certains depuis le wifi, bluetooth ou l'ipod/MTP. Mais j'en connais pas qui puisse s'intégrer à une chaîne deja existante (ie pas d'enceinte mais un audio out).



[1] http://www.parrot.com/fr/produits/enceintes-sans-fil/parrot-(...)

Je profite de cette dépêche pour faire un petit hors sujet.
On a pas de lecteur de musique libre qui soit un peu évolué (genre ipod touch).

Pourtant avec le freeruner [1] (ou les tablettes nokia) on devrait pouvoir faire quelque chose.
Mais faire tourner Rockbox dessus semble un peu juste. Je pense pas qu'il soit adapté à des fonctions aussi poussé (wifi, BT, ...).
D'un autre coté sous Linux on a pas vraiment l'équivalent de Rockbox :
- codec audio/video optimisé pour arm (ou autre processeur embarqué)
- interface sympa pour un baladeur
- gestion de l'energie poussée pour avoir une grande autonomie

Peut être qu'android va changer un peu la donne ?

[1] dommage que l'accélérateur video 2D/3D soit fermé par des NDA http://wiki.openmoko.org/wiki/Neo_FreeRunner_Hardware#Graphi(...) ...

Pour le peu que j'en ai lu ça me fait plus penser à de la paravirtualisation qu'a hurd...

mais il y a le problème du chipset: les chipset non x86 ont souvent été plus cher et moins complet (effet du volume des ventes),
Les processeur arm et mips sont souvent sous la forme de SOC et il n'ont pas besoin de chipset : le chipset et le cpu sont dans la même puce.

C'est clair que du quad core sous 10W, c'est balaise.

Arm fait aussi dans le multi core : le cotex-A9 peut en supporter jusqu'a 4 http://www.arm.com/products/CPUs/ARMCortex-A9_MPCore.html .
Je sais pas combien il consomme, mais quand on sait que le cotex-A8 consomme environ 0.45 mW/Mhz [1], pour 1Ghz ça nous fait 450 mW,on peut espérer que le quad core soit en desous des 10W...


[1] http://www.arm.com/products/CPUs/ARM_Cortex-A8.html