reno a écrit 3886 commentaires

>Il suffit au navigateur de suffixer le nom du processus par le nom de l'onglet / la page en cours.

Oui mais dans les cas ou la page est chargée par plusieurs processus (cas des plugins) il faut faire les additions a la mano: c'est quand même plus pratique que ce soit le gestionnaire des taches intégré au navigateur qui s'en charge.

Pour le chroot, ils appellent ça le sandboxing dans la BD et oui c'est un des but de l'utilisation de processus.

Oh ce n'était pas l'utilisation de 100% du CPU qui me surprenait (j'ai fait exprès d'aller sur un site 'gourmand'), non c'est le fait que pendant quelques secondes quand l'onglet courant utilisait 100% du CPU, je ne pouvais pas changer l'onglet actif.

Je ne suis pas bon en Windows, mais ça m'étonnerait quand même qu'il ne schédule les taches que toutes les x secondes, et normalement l'utilisation des processus devrait pouvoir permettre de garder une interface réactive même quand un onglet devient gourmand.

J'espère que c'est juste un (petit) bug de jeunesse.

Bon quand Flash ne fout pas sa m.., il est plutot reactif comme navigateur.

Et alors? Si les tab partagent le même espace mémoire, tu ne sais pas pour autant quand libérer la mémoire (une tab peut utiliser la mémoire allouée par une autre).

Une possibilité est d'utiliser un GC mais il faut qu'il soit précis car un GC 'conservatif' peut facilement avoir des fuites mémoires..

Bref compliqué tout ça.. Pour une 'optimisation' (remplacer des processus par des thread) qui est loin d'être prouvé comme étant utile.

J'ai essayé Chrome, ça marche pas mal mais la réactivité n'est pas parfaite: quand un onglet occupe 100% du CPU (j'ignore a quoi c'est due), le browser met un peu de temps avant de réagir, sur un multicore ça doit être sympa je pense..

Ce soir: la j'utilise Chrome.

Pour le moment, c'est tout a fait utilisable.
Je n'ai pas trouver le gestionnaire de ressources et apparemment coté DNS il y a quelques corrections a faire, mais sinon ça marche bien.

Je suis curieux de savoir avec quel toolkit Chrome sera disponible sous Linux, intégrer a KDE ça poutrait bien :-)

>Une optimisation est toujours utile

Faux, il y a bien des cas ou des optimisation faites a priori dégrade les performance en finale, en plus en général elle diminue la lisibilité du code, c'est pour ça qu'il faut les faire a la fin, uniquement quand tu as des bench qui te montrent ou optimiser.

>pour ne pas avoir à gérer proprement sa mémoire, ce n’est pas sain

Tu oublie qu'une partie du code executé par un navigateur ne lui appartient pas: plugin closed-source, code intégré a la page.

Même raison pour que le navigateur montre la consommation des ressources..

>Dans la pratique, il y a bien longtemps que j’ai viré flash

Tu as viré flash, c'est bien mais un navigateur n'est pas conçu pour ton cas personnel, les plugins propriétaires ne vont pas disparaitre rapidement, donc un navigateur actuel bien conçu doit les supporter tout en évitant de crasher a cause d'eux, ça implique l'utilisation des processus.

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)..