M a écrit 2996 commentaires

Je sais pas d'ou tu sors tes chiffres, mais il y a 4 ans le salaire d'embauche en ssii d'un débutant sur paris c'etait plutot 28/30k€ sans negocier (35/37 € avec nego).

A 10 ans d'experience, je pense que ca varie beaucoup plus suivant ton parcours...

(ils se basent sur openwrt),
Oui mais bon d'apres ce que j'ai pu lire, pour le premieres versions il a fallu du temps pour que ca soit merger dans openwrt (et c'est venu forcement de fon)

et tu n'as pas de bidouilles à faire pour la flasher.
Ca dépend des modèles (pour certains les premiere version, je crois qu'il faut exploiter un bug du firmware).

Fon fait une comparaison (pas forcément très objective ...) avec d'autres routeurs du même type
Oui mais ils ont oublier d'ajouter les 10€ de frais de port sur leur routeur.
Les différences sont au niveau soft, ce qui est facilement modifiable pour un routeur ou l'on peut installer openwrt (ce que je souhaite).

Ce que je cherche c'est un routeur pas trop cher avec du wifi (au moins 802.11g), avec un port WAN et au moins un port LAN, ainsi qu'un port usb2.0 (high speed). Je préfère avoir un hardware qui tienne la route et qu'il soit pas complètement supporter que l'inverse.

Bref pour faire quel est le (ou les) routeur du moment en france ?

Il y a bien la fonera 2 (wifi + usb2.0) à 60€. Mais je trouve le prix limite cher pour ce que c'est : le hardware n'est pas frachement formidable (flash lente, usb qui ne supporte pas le usb1.0, qu'un port LAN ethernet) et en théorie on doit participer au reseau fon.


En comparaison le netgear WGT634U [1] a l'air bien mieux, mais il n'est plus commercialisé depuis 2005...



[1] http://oldwiki.openwrt.org/OpenWrtDocs(2f)Hardware(2f)Netgea(...)

J'en profite qu'on parle d'openwrt pour demander une page qui récapitulerais les routeurs qui fonctionne bien aujourd'hui (et qui sont encore disponible).

En effet le http://oldwiki.openwrt.org/TableOfHardware.html est un peu bordélique : entre les hardware qui ne se font plus, les hardware dont on se sais pas trop le status, les hardwares dont ne n'est pas sur qu'il tourne sur la dernière version (noyau 2.6) et les hardwares dont on ne sait pas trop quel interface ils ont (usb 1.1 ou usb 2.0, ...) on est vite perdu et il est difficile de choisir un routeur qui serait bien supporté.

Pour la video tu peux jeter un coup d'oeil sur http://multimedia.cx/eggs/icc-vs-gcc-smackdown-round-3/ . Mais c'est pas sur que toutes les optimisations aient été activées

Esperons qui ne fasse pas comme arm (via codesourcery) : ajout des fonctionnalités derniers cris, mais peu de support des procs un peu ancien.


PS : je sais pas d'ou le [1] est deduit, mais le mail reste tres flous : on parle seulement de contribution future...


[1]
C'est en effet, le 10 avril qu'un message de Melanie Blower¹, collaboratrice d’Intel, sur la liste de diffusion de GCC à révélé leurs intentions de collaboration plus profonde, et notamment sur le gcc, les binutils, gdb et la glibc. Ces modifications seront assez importante pour nécessiter une signature d’un contrat de cession de droit².

Si c'est la puissance de calcul qui t'intéresse pourquoi tu ne regarde pas du coté des dsp ?

Je pense que le pb vient de ton choix de ffmpeg qui est quand même un soft bien spécial avec toutes ces routines hyper optimisées.
C'etait le but : tester avec quelque chose de different que le hello word ou un mini bench

De plus si tu regarde le testcase du bug [3], tu veras que c'est du C99 parfaitement valide. Sans aucune extension gcc. D'ailleurs a ce niveau ffmpeg est assez portable dans le fait que le script de configure délecte se que supporte le compilo, et n'activera l'asm inline que si celui-ci est supporté.

Tu a essayé de compiler un autre truc ?
Le noyau Linux, mais je suis pas allé très loin.

Mais bon il faut croire que ca marche chez des gens : http://wiki.freebsd.org/BuildingFreeBSDWithClang


[3] http://llvm.org/bugs/show_bug.cgi?id=3789

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 ?