reno a écrit 3881 commentaires

Je pense que le but de la BD est didactique: même ici quand on dit un processus par tab et les plugin aussi dans des processus séparé la réaction est 'mais pourquoi pas dans des thread?', ce qui est pourtant une réaction stupide de mon point de vue: les processus fournissent une sécurité que les thread n'ont pas, le seul avantage des thread est un gain en performance et en mémoire.

Donc en suivant le principe 'early optimisation are evil', la conception normale dans ce cas la devrait être: processus d'abord et utilisation des thread uniquement si les benchmarks montraient que les performances en souffrent trop..

Je la trouve vraiment tres bien faite cette BD personellement.

Même quand c'est codé dans un plugin closed-source?

>>Les processus dont ils parlent dans leur BD sont apparemment DANS le navigateur, au niveau système il n'en existera toujours qu'un.<<

Ca m'etonnerait: la gestion de la mémoire dont ils parlent et le reste me fait penser a des vrai processus.

Pour moi le gestionnaire de processus de Chrome est juste pour simplifier la vie a l'utilisateur, apres tout si ton gestionnaire de processus de ton OS te dit que le processus Chrome pid XXX utilise 200Mo de mémoire, ce n'est pas tres pratique pour relier ça a un onglet précis et puis c'est incorrect, il manque la taille mémoire utilisé par un plugin dans un sous-process par exemple.

Donc avoir le navigateur qui t'affiche lui-meme les ressources totale utilisée par chaque onglet est bien plus convivial..

Bof, il explique que le multithreading pose des problemes dans l'allocation memoire: fermer un onglet ne redonne pas les ressources a l'OS d'ou le browser qui devient de plus en plus lent avec le temps.

Au moins avec les processus ce probleme est resolu.

Personellement si je choisissais l'architecture du bazar, je ferais un 'composeur' qui gere la fenetre maitre et des processus qui gere les onglets fournissant leur resultat au composeur qui affiche le résultat donc pas de probleme de connection séparée a X11.

Apres c'est une limitation de X11: c'est a X11 d'evoluer pas aux applications de contourner les erreurs de conception d'X11..

Je pense que tu as tort a propos du bazooka: les processus fournisse un mécanisme sain: sécurité, gestion de la mémoire, etc, le partage de la mémoire par multithreading est juste une optimisation.

Et comme toute optimisation il faut prouver qu'elle est utile avant de l'utiliser comme Knuth le dit "premature optimization is the root of all evil".

Avoir une architecture saine n'est *pas* une 'solution de facilité'!!

Un top-like intégré dans un navigateur serait tres utile: cela permettrait de savoir quel onglet te bouffe 100% du CPU et de le fermer, au lieu d'y aller au hasard..

Pas grand chose????

Le manque d'isolation entre les onglets et plugins est la raison pour laquelle je suis passe de Firefox a Opera:
-avec Firefox si un onglet se fige, toute la fenetre se fige
-et par défaut le plugin Flash peut faire planter le navigateur

De mon point vue, ça montre que la conception de l'architecture de Firefox est pourrie^Wperfectible.

Avec Opera, je n'ai pas ce probleme d'onglet et j'en suis satisfait mais c'est du closed source, donc Chrome m'intéresse..

>le hic c'est le fort typage, et les {} ; et autre, qui, quand on vient de python, semblent faire perdre du temps...

Ce n'est pas tellement le typage fort qui fait "lourd" par rapport a Python et autre, c'est le typage explicite: Scala fait par exemple de 'inference de type locale' qui garde le typage fort mais allège la lecture, c'est pas neuf comme concept: Limbo le faisait déjà et ça permet d'avoir les avantages des deux.

Par contre je trouve que la déclaration de variable explicite est une bonne idée contrairement a ce que fait ce langage ou Python: AMHA ça devrait être optionnel, mais présent par défaut: bref l'inverse du Perl.

Pour ce qui est de {}: un prof a trouvé qu'en utilisant une syntaxe a la Python pour l'indentation (enfin il n'est pas fou lui, il n'a autorisé que les espaces pas les tabulations!) les débutants avaient plus de facilité a apprendre un langage: ce qui est interressant c'est qu'il a changé juste ce point et garder le reste a l'identique pour faire la comparaison.

>>Comparer les fréquences de CPU différents pour imaginer leur puissance, c'est de la grosse connerie.<<

N'exagérons pas, la fréquence est un indicateur, incomplet d'accord mais un indicateur quand même: entre deux CPU un a 100MHz et un a 1GHz, j'aurais tendance a dire que celui a 1 GHz sera plus rapide (avec un FPGA ou un ASIC contre un CPU cela pourrait être différent).

>>1.6 GHz pour l'Atom, l'Atom devrait alors être une grosse merde comparés aux anciens CPU d'Intel à 3 GHz, mais il en est rien, car la fréquence d'un CPU ne donne absolument pas sa puissance.<<

Ca c'est amusant: un Atom a 1.6 GHz est estimé a 653 SPECint ce qui est deux fois moins qu'un un P4 avec le double de la frequence: 3.4GHz Pentium 4 Northwood = 1393 SPECint.

Donc tu as choisi pile le mauvais example, un meilleur choix pour montrer que la frequence n'est pas tout est l'Itanium2 qui a 1.6GHz a 1590 SPECint (bien oui c'est un VLIW).

La raison pour laquelle, les gens considerent que le P4 est une merde et pas l'Atom, c'est le rapport puissance/consommation électrique pas la performance pure: l'Atom est in order donc pas si puissant que ça a une frequence donnée.

Moi je les trouves sympa tes graphismes: ils ont un coté retro amusant.

Perso, ce qui me derange dans les jeux libres c'est plutot que l'IA est inexistante, bon je ne les ai pas tous testé..

Euh en quoi c'est mieux?

Le CPU consomme probablement moins mais 900MHz contre 1.6GHz (Atom), je ne suis pas sur qu'au niveau performance ce soit compétitif (et puis il ne faut pas oublier que le CPU ne represente qu'1/3 de la consommation globale) et a part le CPU, le reste ressemble aux petit laptops a la mode actuellement...

Dommage qu'il n'y ait pas de laptop disponible qui s'inspire de l'OLPC XO-1: pouvoir lire l'écran en plein soleil, être tranquille au niveau de la robustesse, ça m'intérresse plus que le jeux d'instruction du CPU utilisé!

Dans les autres revues que j'ai vu le Nano (plus puissant) était plus gourmand que l'Atom mais le chipset utilisé par l'Atom était trop gourmand et au final ils utilisaient tous les deux a peu pres la même puissance.

Les petit laptop utilisent quasiment tous des Atom, je n'en connais aucun avec Nano, j'ignore pourquoi mais comme tu dits la concurrence est rude!

Bon deja les VLAN sont au niveau 2 pas au niveau 1.

Pour le reste il faut lire la documentation du switch s'il supportes les VLAN ou pas, mais a part ça DHCP (niveau 3) est tout a fait compatible avec les VLAN (bon il faut s'assurer que le serveur DHCP soit dans le broadcast, mais puisque tu as deux cartes sur ton serveur Ubuntu ça ne doit pas poser de probleme).

Remplacé?
Par les successeurs d'Atom oui, mais pas par les Atom actuelles qui jouent dans une catégorie différentes (performance plus élevées que les ARM mais consommation plus élevée aussi) donc pour une utilisation différente..

L'Atom est pas mal dans sa catégorie au niveau consommation electrique, mais coté chipset, c'est loin d'être ça..

Tes arguments ne me paraissent pas convaincants: sur la *même* configuration Linux et Windows étaient deja beaucoup plus lent a démarrer que BeOS.

Et le temps de démarrage de Linux a eu tendance a diminuer pas augmenter (même s'il reste très supérieur a ce que BeOS fournissait).

Pour ce qui est de la programmation objet, BeOS utilisait pas mal le C++, donc deja objet.

Et il reste la réactivité, BeOS était tres reactif, la raison principal est qu'originellement il était prévu pour une machine bi-processeur donc ils ont fait attention a utiliser le threading partout, ce qui a l'effet de bord tres agréable d'avoir un systeme tres réactif même sur un mono-processeur, alors que par exemple une fenêtre de Firefox se fige parfois quand un onglet est occupé: mauvaise conception ou tout au moins conception pas adaptée pour avoir une bonne réactivité.

La tu exageres, dans n'importe quel langage, la gestion des nombres réel est quelque-chose de compliqué: ça tiens plus a la nature du probleme qu'autre chose, même si on utilise une autre représentation qui évite les problemes de précision avec 0.1, il est facile de trouver d'autre problemes simples qui causent des problemes. (1/3, pi et autre).

Et je dirai que le problemes des nombres flottant est qu'il font paraitre simple un probleme qui ne l'est pas..

Note que ça dépend ou: j'imagine que dans un endroit pauvre effectivement ça doit être difficile a trouver.

A Carmel (un Honfleur pour riche en Californie), sans même chercher, j'ai vu une fromagerie qui avait l'air bien achalandée (pas fait attention s'il y avait du fromage au lait cru ou pas): normal, c'est une question de clientèle: les Californiens riches voyagent plus a l'étranger et il y a donc de la demande pour des produits peu connu par l'Américain normal.

>>FOSDEM est avant tout animé par des développeurs pour des développeurs. N'espérez pas voir des bureaux 3D<<

Mouai, la fois ou j'y suis allé, une des conférences qui avait eu le plus de succés était sur les effets 3D sous X justement.

Donc les developpeurs aiment aussi les bureau 3D.

Mais c'est vrai que certaines conf sont vraiment voici le code, lisons le pour comprendre comment ça marche.

Certes mais ton Atari avait son OS en ROM, BeOS utilisait un PC 'normal' mais il bootait plus vite et était plus 'responsif' sur un Celeron 333 que Windows ou Linux le font maintenant sur des machines 10 fois plus puissantes..

Pourquoi? Meilleur conception essentiellement (meilleur utilisation du threading).

Le plugin Flash plante t'il Firefox?

Certaines distributions utilisent nsplugin pour eviter que le plugin flash plante Firefox, d'autre pas..

Bien sûr, ça ne devrait pas être aux distributions de corriger les faiblesses de Firefox: Firefox devrait *par défaut* integrer nsplugin et l'utiliser pour tous les plugins non-géré par le projet: intégrer du code 'étranger' dans ton espace mémoire est une très, très mauvaise idée pour la stabilité.

Enfin si Firefox avait une bonne architecture, ça se saurait (une tab peut figer toute la fenetre berk)..

Ils ont les codec et la lecture de DVD installé de base, ce qui n'est pas si fréquent (ce qui est un peu frustrant pour les codec d'ailleurs car il s'agit d'un probleme principalement américain qui "déteint" ailleurs).

Je t'ai plusser avant de changer d'avis:
1) ça n'a couté que quelques octets et c'était interressant de savoir qu'il y a un magazine sur Linux en langue arabe (même si je ne parles pas Arabe).

2)les réactions montrent que les gens ne sont pas hostiles a parler des magazines en langues étrangères et il y en a de très bon: a une époque Dr Dobbs était inégalé et si je ne parle pas Allemand les quelques articles que j'ai pu voir en Anglais de c't m'ont paru très bon.

Puisqu'on parles des magasines étrangers, il y a quelques années, j'avais été surpris de voir qu'a Palo Alto (en plein coeur de la Silicon Valley) il n'y avait pas tant que ça de magasines qui parle de Linux..

Note que pour le 'highlight', ce n'est pas tres etonnant que l'anti-aliasing foire, c'est probablement une operation de changement de couleurs trop rapide.

Pour ce qui est du rendu, ce n'est pas forcement de la faute de Qt, ça depend probablement aussi de la façon dont on le configure.

Est-ce que la specification contenait d'utiliser des entiers 16bit pour enm.. les utilisateurs?

0)Non, mais les analogies comme souvent ne servent pas a grand chose.

1)Je n'ai jamais dit que le tableur était l'outil idéal pour des fichiers avec 100 000 lignes, mais je pense quand même qu'il devrait le supporter: ce n'est pas a l'outil de définir le mode d'emploi, point.

2)Le tableur n'est pas le plus performant pour les gros fichier, mais c'est du temps d'*ordinateur* dont on parle, apprendre a utiliser un autre outil c'est un investissement en temps *personnel*: c'est a chacun de voir ou il veut mettre la barrière.

3)Je suis tout a fait d'accord que le tableur remplace trop souvent une base de donnée, mais le choix ne devrait pas être imposé a cause d'une restriction artificielle.

4)Tiens, puisque tu parles d'emacs: sait-tu qu'une des grandes avancées des outils GNU des le depart était d'utiliser ... des entiers 32 bits!
Et a l'époque c'était loin d'être évident (mémoire pas si grande que ça) mais RMS a pris le parti d'utiliser des entiers 32bit, ce qui était une *bonne* idée.

Alors une appli qui utilise des entiers 16bits en 2008 (hors cas tres particulier), je rigole.

5)La notion d'une tache, un outil sous Unix, ça fait longtemps, (depuis les IHM en fait) qu'elle est appliquée de manière très, très "fluctuante".
De GNU tar qui fait la compression; a Perl qui remplace sed+awk, a Mozilla qui fait mail+navigateur, a Konqueror qui fait tout, Thunderbird qui fait email et newsgroup, etc
une tache = un outil faut le dire vite!!