reno a écrit 3881 commentaires

1) Les être humains sont lents par rapport à des processus.
2) Chrome me parait bien plus réactif que Firefox donc le multi-processus n’empêche donc pas de faire un browser réactif..

tu t'échines à voir la séparation en processus distincts comme la recette ultime de la performance.

Tu te trompes, pour moi les 2 intérêts principaux sont: 1) la sécurité ET 2) la réactivité.

(1) est aussi important que (2).

La séparation en processus n'est pas la recette ultime de la performance mais au moins ça nettoie simplement les ressources quand on ferme un onglet: ça n'est plus un problème avec FF mais ça l'a été pendant très longtemps.

Alors les multiple sens de The Hurd, je te les laissent.

Oui, c'est vrai, quand tu as une action sur l'interface, en général, tu ne veux pas que le navigateur réponde instantanément.

N'importe quoi, je faisais remarque que dans un OS, les processus communiquent souvent entre eux par contre dans un navigateur web, les sites web ne communiquent pas entre eux (enfin rarement), ça n'est pas très compliqué de voire la différence non?

Une autre remarque: Hurd est un noyau, pour les noyau la vitesses des IPCs est extrêmement importante, les noyaux monolithiques ont donc un avantage important.
Dans un navigateur web, la situation est totalement différente..

T'es tu demandé si séparer en processus n'avait pas des inconvénients ?

J'y ai réfléchi effectivement.

Comme une consommation mémoire plus élevée,

C'est a peu près le seul réel inconvénient, mais note que Chrome te permet aussi de tout mettre dans le même processus, donc quand tu as une mémoire très restreinte, tu peux le configurer de la sorte: pouvoir avoir un processus par site web, n'implique pas forcément d'utiliser un processus par site web..
Et il y a beaucoup de machines avec beaucoup de RAM ou utiliser un peu plus de mémoire n'est pas un gros problème.

une moins grande souplesse dans l'écriture des addons

De toute manière, il faudrait 2 niveaux d'addons: une API interne qui peut tout faire mais avec lesquels tu n'as pas la sécurité et une API externe qui est dans un processus séparé: moins de souplesse mais tu as la sécurité.
Chrome ET Firefox sucks tout les deux car ils n'ont pas ces 2 niveaux.

plus d'optimisations/codes en fonction de l'OS, etc.

Oui euh Chrome est plus performant que Firefox donc visiblement ils ont réussi a surmonter l'obstacle.

Tout dépend des cas et surtout de l'architecture.

Ce qui est rigolo c'est que le sujet initial de l'article Firefox a toujours une architecture pourrie rapport à Chrome car ils n'ont pas le support d'un processus par site web et qu'ils ont renoncé à travailler sur le sujet car ça ferait trop de changements..

Il y a un communiqué de presse de Digia qui semble indiquer que oui.
En théorie, c'est comme si on renommait TrollTech en Digia, en pratique ce ne sont plus les mêmes chefs, plus la même époque (y a t'il toujours un marché pour du support Qt maintenant qu'il est LGPL?)..

Il peut se tromper mais est rarement un menteur.

Hum, il y a les deux: regarde la religion Mormone, la religion Scientologue, Machiavel (et d'autres) qui poussait pour une religion d'état pour mieux controler le peuple, les papes qui avaient un conportement tout sauf Chretien mais qui en retirait tout les bénéfices, etc la liste est longue..

Le père Noel me dérange beaucoup moins que les contes pour enfants qui glorifient les castes (noblesses, princes, etc).

Haskell avec sa lazyness par défaut pose des problèmes coté performance: j'ai lu ça dans un papier qui donnait un retour d'expérience sur haskell dans la "vrai vie"

Pourquoi pas C#? Son principale problème est que c'est un langage qui vient de Microsoft, qui, étant donné ses actions dans le passé n'est pas digne de confiance, autrement c'est un bon langage je trouve, tu lui reproche quoi?

Note que des langages à typage statique bien conçu j'en connais assez peu finalement : Ada, Ocaml/F#, C#.

Je ne compte pas Scala et D car ils ne détectent pas par défaut les débordements entier.

Ce que je trouve très intéressant dans le dev de LibreOffice c'est que les gars sont parti d'une base de départ énorme, bien "bordélique" (commentaires en Allemand, code mort, etc) mais plutôt que de se dire on va tout réécrire(1), ou bien on va faire des plugins pour tous les nouveaux développements(1), ils attaquent le problème de front (cf le blog de Meeks) et là je suis super impressionné!
Ce que je ne comprends pas trop, c'est pourquoi ce style de développement "progressif" ça marche pour LO, mais pas pour les environnements de bureau..

1:comme c'est trop souvent le réflexe dans le monde du logiciel libre (bon pas uniquement)

C'est quoi "default(none)"?

Bah, justement l’intérêt principal de la "langue Unix" est sa productivité (son inconvénient principal est sa difficulté d'apprentissage).

Moui, pas convaincu, les GUI ont vraiment tout balayé sur leur passage (pour les utilisateurs pas pour les admins) et le mode texte d'Unix s'est retrouvé bien isolé, pas convaincu qu'on retrouve jamais la "langue" Unix.

Quelqu'un a parlé d'Etoilé (sur osnews) comme les GUI 'à la Unix' mais je ne suis pas vraiment convaincu.

Et je vois 2 gros problèmes pour le mode texte sous Unix:
1) les GUI comme dit ci dessus qui le concurrence

2) le manque d'évolution: VMS avait une syntaxe plus logique que celle du shell Unix, pourquoi un équivalent n'a t'il pas été adopté? PowerShell est pour moi une évolution logique du shell, mais il n'a pas été crée sous Unix..

Les artworks ont ceci de particulier qu'il sont difficilement réutilisables (telles des briques) comme du code source.

Faux:
1) tu peux réutiliser les artworks en changeant l'histoire, le style du jeux: cf les mods.
2) tu peux changer les paysages/décor et garder les personnages ou vice versa.
3) tu peux "mangaifier", cartoniser des personnages (même de façon partiellement automatique)

Bref tu as parlé beaucoup trop vite.

On interdit pas le fork sur le code source, qui est le coeur du jeu.

Le code source est le coeur du jeu?
Euh ça dépend beaucoup du jeux! Dans beaucoup de jeux la réalisation des graphismes prend plus de temps que pour réaliser le moteur du jeu!

Donc non, un jeux dont les graphismes ne sont pas libre n'est un pas un jeu qui respecte l'esprit du libre: Doom3, Quake sont d'autre jeux qui ont des graphismes propriétaire et un moteur avec des sources libres, ça n'en fait pas des jeux "libre", des moteurs de jeux libre OK.

Pas moi, sur Solaris il y avait une application sur le bureau CDE qui ne fonctionnait pas en déport d'affichage(!), beurk!

Hum, le sandboxing dans les navigateurs n'est pas spécifique à Flash, c'est juste un design de bon sens pour la majorité des plugins d'un navigateur: Firefox n'est pas un exemple à suivre au niveau design.

J'ai la même analyse mais ça n'en fait pas une remarque honnête pour autant: everybody != Valve.

À quoi ça sert d'afficher les applications qui ne font pas de son dans le mixeur de son ?

Pourquoi c'est modéré positivement ça??
Firefox peut beeper, jouer de la musique et même un beep c'est un son!

Alors je t'aide: FUD: Fear Uncertainty and Doubt, donc quand Gabe Newell "Windows 8 is a catastrophe for everyone in the PC space.", ça c'est du FUD: une affirmation pour faire peur sans réelle justification.
Quand un dev dit on a 315FPS dans X et 303FPS dans Y, ça ce n'est pas du FUD, c'est une information.

Pour le reste je suis d'accord avec toi, Valve a tout intérêt à ce que d'autre producteurs de jeux fassent la même chose: avant de se battre pour avoir la plus grosse part du gâteau, il faut faire le gâteau!

Je suis intervenu sur la mailing list de Phoronix, car certains points de Paul Davis me paraissaient un peu "rapide":

En résumé je trouvais que bien que la mémoire partagée n'utilise pas d'appel système mais qu'il faut bien utiliser des IPC en plus et que le tout 'pull' ne me parait pas satisfaisant dans tout les cas (jeux par exemple) et donc des modifs du kernel pourraient être intéressant.

Et bien il m'a répondu fort poliment:
http://phoronix.com/forums/showthread.php?72625-KLANG-A-New-Linux-Audio-System-For-The-Kernel&p=278764#post278764

Apparemment quasiment tout les points de l'auteur de KLANG m'ont l'air mort, mais il y aurait quand même quelque chose a faire: Paul Davis trouverait super d'avoir une modification d'ALSA pour supporter aussi une interface à la CoreAudio..
Si je ne me trompes pas ça revient à importer une partie de ce que fait PulseAudio dans le kernel pour une meilleure efficacité..
Dommage que l'auteur de KLANG n'ai pas eu cette discussion avec Paul Davis avant de démarrer KLANG, ça aurait pu être un projet intéressant!

J'ai appris les bases d'OpenGL il y a 10 ans et mes connaissances sont toujours valables, l'api ayant évolué par extension.

Vrai et faux: si tu utilise OpenGL comme à ses débuts, ton application ne pourra pas exploiter efficacement la carte vidéo.

Ton commentaire n'est pas faux, mais Paul Davis précise que le système en question n'utilise pas ALSA donc pour ce cas précis ça n'est pas un problème, mais je suis d'accord: dans le cas générique le calcul entier ça pose des problèmes.

Aussi Paul Davis précise qu'il y a deux façons d'avoir des systèmes audio: le pull (la carte son annonce qu'elle a besoin de données supplémentaire et les applis fournissent), le push: les applis fournissent les données et précise que le pull est le plus répandu et qu'avec une bufferisation ont peu faire du push sur du pull mais pas l'inverse.

Sauf que une appli voulant 1) que le son prenne peu de ressources 2) avoir quand même une faible latence (par exemple un jeu) ne me parait pas bien servi par ni par un pull (car pour la faible latence il faut définir des buffers de petite taille donc beaucoup d'interruption) ni par un push bufferisé sur du pull, donc un kernel qui fasse du pull (parfait pour les applis pro de multiplexage) et du push (bien pour les jeux) ça ne me choquerait pas..

Après je ne suis pas spécialiste en audio!

Avec le smiley j'ai cru que c'était une plaisanterie..
Effectivement je compte C# parmi les langages avec un comportement sain pour les entiers.