reno a écrit 3886 commentaires

Pas les mêmes problèmes; pas les mêmes besoins..

Les dual core dans les mêmes conditions ferait une drôle de tête, s'il le ventilateur lâche au fin fond de l'Uruguay ou qu'il faut l'alimenter avec des cellules solaires..

D'un autre coté, c'est vrai qu'on est tellement habitué à nos bête de course moderne que ça fait mal au dent de voire un OLPC démarrer: il ne faut pas être pressé!!

>En général, les personnes qui lisent l'assembleur générés par gcc disent qu'il est débile car il rajoute plein de load/store parfaitement inutile.

Euh, pourquoi tronquer les résultats?
Avoir des bits significatifs en moins c'est mal ok, mais en trop, à part dans des cas très particuliers, je ne vois pas ou est le problème, j'espère que ce n'est pas activé par défaut..

>L'Uruguay offre des laptops sous Linux à ses élèves de primaire

L'Uruguay subventionne l'achat de laptop pour les élèves du primaire.

'Offrir' sous-entend plutôt que c'est un cadeau..

Je doute très fortement que le gouvernement Uruguayen considère ces laptops comme des cadeau, mais plutôt comme un investissement dans des 'outils éducatifs'..

De plus en plus, je pense que les hierarchie de répértoire pour acceder aux fichiers sont problematiques car artificielle..

Apres la perte de performance est-elle acceptable?
Je l'ignore..

> Note tout de même que bien évidement, on peut créer des threads dans tout les sens dans Mozilla (c'est beaucoup utilisé dans Gecko bien sûr)

Certes, mais les thread pour la gestion des ressources, c'est insuffisant..
C'est d'ailleur plutot satisfaisant avec Chrome de trouver le site web qui fait que ton navigateur utilise 100% du CPU et de tuer le processus correspondant en 5seconde, plutot que d'y aller par essai/erreur avec Firefox..

D'ailleurs puisqu'on est sur LinuxFr, je dirais que la philosophie Unix d'utiliser par defaut des processus est sage: les threads ne devraient être utilisé que pour l'optimisation mémoire quand on maitrise la totalité du code (ce qui n'est pas le cas d'un navigateur puisque les pages web contiennent du code).

Oups, je devais manquer de vitamines ce jour la. Désolé.

>Utiliser une techno comme le XUL/HTML, ça a de nombreux avantages, dont la capacité à pouvoir être modifié à la volée, à être modifié via des extensions (grâce aux overlays),

Puisque apparemment tu connais le sujet: est-ce que ces capacités sont utilisée en pratique?
Je connais plein de librairie super-compliquée dont les capacitées avancées ne sont pas utilisée..

D'ailleurs il me semble qu'il y a très, très peu d'application utilisant XUL, comparé au nombre d'applications qui utilisent GTK ou Qt..

Tu parles des avantages en laissant un poil de coté les inconvénients: à une époque on m'avait expliqué que FF ne pouvait pas utiliser un processus par onglet car l'emploi de XUL ne permet pas cela.. (je crois que cette discussion était avant que Chrome sorte d'ailleurs: c'est une idée assez logique)
Mais j'ignore si c'est vrai ce point, après tout les developpeurs de Firefox bossent sur ce point pour FF4 et comme ils vont probablement garder XUL, cela devait juste être une limitation de l'implémentation..

Pour un developpeur les temps de compilation a mesurer seraient aussi avec '-O0 -g' pour les versions intermédiaires..

>C'est un peu concon comme argument ...

N'importe quoi, c'est même l'argument principal contre les logiciels propriétaire: en général ils utilisent des formats propriétaire ce qui limite la réutilisation des données..

Ce qui explique par exemple pourquoi Microsoft a baisé l'ISO pour faire 'normaliser' leur format de données..

>sait faire des optimisations dont GCC est incapable

J'ai l'impression d'entendre un homme politique parlé la..
Techniquement ce que tu dis est vrai, mais cette tournure de phrase est trompeuse: ok LLVM est capable de faire des optimisations que GCC ne peut pas faire, mais la vrai question est: lequel optimise le mieux?

La dernière fois que j'ai vu un comparatif (qui n'était pas avec la version 2.6 pour LLVM bien sûr) c'était GCC qui générait des exécutables plus performants.

Fiabilité vs performance, l'éternel compromis: je me souviens d'un essai de désactiver le cache en écriture des disques afin d'éviter des problèmes de corruption de FS, les performances étaient tellement mauvaise qu'on l'a réactivé..

Le plus dommage la dedans, c'est que si les disques SATA/IDE ne mentaient pas a propos de "quand les données sont écrites réellement sur le plateau" on pourrait avoir de meilleure performance de manière fiable, mais a ce moment la les benchmark seraient moins favorable
--> les constructeurs optimisent leur disques pour les benchmark et non pas pour la vie réelle, quelle ironie..

>Ensuite tu oublies que Microsoft est un rouleau compresseur et que je ne pense pas qu'il soit mal barré (enfin ca va dépendre de Windows Mobile 7).

Ah? Les reactions lors de la sortie de Windows Mobile 6.5 ont pourtant ete unanime: c'est de la M...

Microsoft peut-il rectifier le tir avec WM7?
C'est possible bien sur, mais j'en doute..

Note qu'il existe deja des personnes qui font ce genre de test de non-regression,Phoronix n'a donc rien fait de nouveau, ceci dit plus il y a de testeurs mieux c'est bien sur, donc j'applaudis bien fort leur travail.

>Peut-être moins sexy que son cousin Ruby, mais tellement efficace ;)

Comme c'est Vendredi, je vais repondre a cela: 'tellement efficace'?
Ruby et Python sont tous les deux tres lents.

'Moins sexy'?
A une epoque je voulais apprendre un nouveau langage de script (je n'aime pas le shell, je deteste le Perl) et j'avais regarde les 2: ma conclusion est que les deux etait vraiment tres, tres similaire en fait.
Mais depuis quand je vois les nombreux changement 'subtils' de Ruby 1.8 -> 1.9 et en comparaison le faible nombre de changement Python 2.x -> 3.x, je me demande si le choix de la simplicite pour Python n'est pas le bon choix plutot que d'avoir une syntaxe 'sexy' qui peut facilement se transformer en 'trop compliqué'..

Note que si je savais que microcode n'est pas correcte, il a fallu que j'aille chercher sur wikipedia la traduction correcte de firmware: je ne m'en souvenais pas, elle n'est pas très utilisée..

Merci pour tes articles.

Je pense que c'est une question de defaut: par defaut dans BeOS tu as les traitements dans les thread 'moteurs' il me semble et en plus la machine cible au départ était bi-coeur --> utilisation importante des threads dans les appli fourni par l'OS lui meme, guide de programmation indiquant la manière correcte coder une application qui utilise des threads, etc.

Par defaut dans les GUI sur Linux en regle generale, les traitement sont dans le thread du GUI et si tu es motivé alors tu peux utilisé des thread/process pour faire les traitement: résultat pas beaucoup d'utilisation des threads..
D'autant plus que c'est quand même très récent que tout le monde a un bi-coeur dans le monde x86.

Aller contre la fainéantise/recherche de simplicité des developpeurs n'est pas naturel: de la meme maniere qu'il a fallu attendre Chrome pour que les developpeurs de FF soient motivés pour avoir une architecture correcte (de mon point de vue), si Haiku a du succés (très peu probable: Syllable qui est assez semblable n'est quasiment pas utilisé) peut-être qu'un desktop sous Linux sera motivé pour faire les (gros) changement necessaire..

Si je ne me trompe pas OSS n'existe que sur les Unix, ce qui laisse de coté Windows..
OK, c'est 1000 fois mieux qu'ALSA qui est limité à Linux uniquement mais cela reste très insuffisant je pense..

>Et d'ailleurs, ça contient quoi un microcode ?

Remplace microcode par firmware/micrologiciel: c'est une erreur de traduction.

Ce que Debian a fait c'est mettre dans un espace à part les binaires chargés sur les périphériques qui sont non libres. On appelle normalement ces binaires firmware ou micrologiciel pour faire la difference avec les logiciels/software qui tournent sur le CPU principal.

Le microcode est du logiciels qui tourne dans le CPU lui-même (donc pas restreinte au jeu d'instruction (ISA) 'externe' du CPU) et utilisé par les constructeurs pour corriger des bugs, implementer des instructions trop compliquees pour le hardware.

Il me semble que tout les CPU x86 ont un microcode, et typiquement ce microcode n'est pas libre donc même si tout les pilotes de peripheriques utilisé sur un PC étaient libre, un PC x86 executera du logiciel non libre..

> L'impression de vélocité donné par Windows est une impression bien réelle et nullement sujete à troll. Pour l'expérience utilisateur, mr michu voit clairement que Windows "va plus vite". Point.

Je ne suis pas d'accord avec toi, ce sont plutôt les 'experts Windows' qui peuvent avoir un Windows "rapide" (tout est relatif hein: bien moins que BeOS): un utilisateur normal a un anti-virus tournant en permanence sur son PC et celui-ci lui bouffe tellement de ressources qu'il ne va pas trouver forcément que Windows est rapide..

>J'avais vaguement compris que Windows utilise massivement les thread, me trompe-je ?

"Massivement" pas forcément mais les processus étant lourd sur Windows c'est exact que les thread sont y plus utilisés oui.

>En y repensant, est-ce que c'est pour ça que Windows est plus réactif qu'un gnome ou qu'un KDE sur ma machine?

J'en doute: la réactivité de Windows est très, très inférieure à celle que BeOS avait (sur des machines beaucoup moins puissante)..

Je pense que c'est plutôt qu'il y a peu de version de Windows avec beaucoup de part de marché donc plus d'optimisation contre beaucoup plus de baz^Wdiversité sur Linux.

Je ne suis pas un expert en Python mais j'avais l'impression que les changement 2.6 -> 3.x n'étaient pas si important que cela..

En tout cas par rapport a Ruby 1.9, c'était l'impression que j'en avais..

> [coupé] que d'énergies dépensée en projets redondants uniquement pour des incompatibilités de licenses libres !

Tu te trompes: la BSD 2clause (utilisée majoritairement par OpenBSD) et les GPL sont compatibles sur le plan technique, le probleme est d'ordre 'philosophique': les developpeurs des OS *BSD veulent avoir des outils sous licence .. BSD! (ou equivalente: MIT, etc).


> alors qu'on a à peu près 10 serveurs de messagerie, 5 serveurs http, etc., à quand une vrai alternative à Office et Visio dans le domaine de la bureautique, à quand un Xorg vraiment modernisé, etc. ?

C'est plutot un probleme de complexité a mon avis..
Il n'est pas surprenant que plusieurs personne developpent des projets equivalents pour des projet de faible complexité (un serveur http de base, c'est vraiment tres simple a coder) par rapport a Office/Visio/Xorg et autres projets d'une grande complexité..

> mais un peu plus de cohérence et de gouvernance feraient avancer les choses...

Euh, certes mais le probleme est:
- il est tres difficile de gagner de l'argent sur le desktop donc les professionels se concentrent sur les fonctionnalite des serveur: peu d'argent est investi pour le developpement des fonctionnalite desktop.
- les 'amateurs' avancent lentement sur les projets complexes..

Tu comptes resoudre ce probleme comment? En postant sur LinuxFr?

>Scala de plus que les autres ce langage ?
>
>Ca fait longtemps que ca existe les langages multiparadigmes: fonctionnel+objet+impératif

Ce n'est pas Vendredi alors je vais essayer de repondre sans generer de troll (mission impossible). Deja par rapport a tous les autres langage que tu propose Scala a l'avantage de pouvoir acceder facilement au code Java existant.

Plus specifiquement:
-Par rapport a CLOS, ScmObj (Scheme): Scala a pour avantage sa syntaxe, celle de Lisp/Scheme n'est pas tres populaire..

-Par rapport a CLOS, ScmObj (Scheme),Ruby: Scala a pour avantage
1) typage statique avec inference locale, ce qui permet de n'avoir pas beaucoup plus de declaration de type tout en gardant une securite supplementaire
2) les performances (quasiment les memes que celle de Java).

-Par rapport a Ocaml, je dirais que l'avantage principal c'est d'etre un vrai mix fonctionnel / objet+imperatif alors qu'Ocaml est aborde principalement par son cote fonctionnel, au moins dans le manuel que j'avais lu..

Finalement, c'est bien le javascript alors..

Oui, c'est un troll, mais j'ai le droit: on est Vendredi!

Merci d'avoir rectifié, cela me hérisse à chaque fois que quelqu'un clame que Wayland est un remplacant d'X ou d'Xserver alors qu'il n'en remplace qu'une petite partie des fonctionnalités..

Comme J'ai une question:
-Compiz est un gestionnaire de fenetre qui 'compose' les fenetres.
-Wayland est un serveur d'affichage qui 'compose' des buffers GEM.

Y a t'il un rapport (dans le concept) entre ces deux types de composition?