Re: Opera v5?

Les gestionnaires de fenêtres qui maintiennent des sessions sont totalement bloated

À ce niveau, mon problème principal, c'est que je ne sais pas définir précisément ce qu'est une session. Sérieusement. Je suis au courant des problèmes d'i3, ou du moins de certains. Par exemple, il est très difficile et très aléatoire de répartir comme on le veut un groupe d'applications dans un workspace.
Je me plante peut-être, mais, pour moi, ce point particulier est lié au fait qu'i3 ne permette pas d'«opérations atomiques». Évidemment, c'est facile à dire, mais pas à faire.
Ce qui ne m'empêchera pas de penser (et, espérons-le, un jour d'agir?) que le gestionnaire de session et le gestionnaire de fenêtres sont aussi des choses distinctes.

Awesome est plus sympa pour faire ce genre de chose. C'est un wm "automatique". Tu peux configurer des choses de manière totalement automatique. Mais c'est largement plus complexe à utiliser que ce que propose Firefox.

Pour être franc, je pense que je manque de recul sur la réflexion qu'il doit y avoir encore gestionnaire de session, gestionnaire de fenêtre, décorateur de fenêtre (pour le coup, i3 (que j'utilise au quotidien) est un bloatware: il fait wm, décorateur, et gère en partie les sessions puisqu'il colle toujours une status bar avec des info obligatoires... entres autres, mais c'est le plus proche de mon équilibre perso)...

Je ne sais pas découper peut réduire la cohérence et rendre les choses plus compliquée à faire.

Hum hum... Tu as des cas un peu répandu où tu va nous donner un lien d'un rapport de bug plus ou moins obscure ?

C'est vrai, je n'ai aucun bug report ni report à citer
Mais, que se passe-t-il si un thread plante? Sur ce point de la discussion, j'ai tout à gagner: soit je me plante, et j'apprend comment une application récupère d'un crash de thread (big win), soit je gagne un échange sur dlfp (peu probable) qui fera réfléchir avant d'utiliser du multi-thread (encore pire).

Ça dépend de ce que tu fais et de la technologie que tu utilise. Java et .Net ont des pool de threads qui sont gérés chacun son tour. Pour Firefox je présume qu'il ne fait que de l'interprétation (du DOM HTML, du JS, des images,...). Il n'est pas si compliqué de gérer les erreurs d'un méta-langage dans un langage (modulo certaine erreurs de sécurité) et on peut utiliser des tests de fuzzing pour vérifier avec des données aléatoires.

D'un autre côté, il est simple de protéger une IPC contre un crash des interlocuteurs, et au niveau code, c'est quasi trivial de savoir qui bug, alors que du multi-thread... c'est pénible à lire, pénible à debug, pénible à maintenir.

C'est pour cela que Rust existe (pour de bon, c'est vraiment pour ça qu'ils l'ont créé). Ce qui fait choisir entre des threads et des processus, ça va souvent être le rapport entre la puisance de calcul nécessaire et les besoins de communication.

Le multi-processus consomme beaucoup plus de ressource.

C'est un fait. Relativement à un thread, il faut sauvegarder beaucoup plus d'informations. D'un autre côté, c'est de toute façon fait par le kernel, vu que de toute façon les processus résident quelque part?
Cela dit, sur nos systèmes de bureautique, cette consommation de ressources supplémentaires est-elle significative? On parle de quelques kibi octets, la on l'on dispose de plusieurs de gibi octets. À moins que tu ne parles de performances CPU? Dans ce cas, le problème vient-il des erreurs de cache? De cycles gâchés?

Si le noyau ne fait du COW sur les pages mémoire, il reste une quantité de données que tu va devoir recopier entre tes fils d'execution. Tu prend le DOM, tu construit un arbre que tu va pouvoir manipuler pour fournir l'API DOM, mais ausi pour pouvoir faire une navigation CSS et tout ce qui est interne.

Si tu utilise des processus, il va falloir serialiser toute cette structure (qui n'est pas petite) pour la deserialisée de l'autre coté.

Il faut se rendre compte que l'objectif de quantum n'est pas d'avoir un thread par onglet, mais d'en avoir plusieurs ce qui augmente encore les besoins de communication.

Je t'avoue, moi, je ne sais pas, à quel point un multi-thread est plus lent, sur un système moderne, qu'un mécanisme d'IPC, comparé au temps d'exécution total.
Cela dis, si tu as de la doc, je la dévorerai (enfin, un peu comme pour le vin, seulement si elle est bonne :p).

C'est un bench à faire ça dépend de la granularité que tu souhaite.

ils ont pris une bibliothèque qui fait déjà bien le job

Laquelle? Est-ce vraiment son job, ou son job est-il plutôt de permettre de tisser des relations entres les données, «bêtement»? Est-il possible d'interagir simplement de l'extérieur sur cette BDDR?

~/.mozilla/firefox/<ton profile>/places.sqlite tu peux y accéder avec la commande sqlite (faut la version 3).

Soyons honnêtes: si tu veux faire adopter le panda roux, tu ne mettras quand même pas ça en exergue, si?

Tu ne me verra jamais « faire adopter ». Les gens font bien ce qu'ils veulent de leur machine.

Et perso, j'aurai tendance à considérer ce genre d'outils comme des plug-ins, vu qu'ils ne concernent réellement qu'un très faible nombre d'utilisateurs, alors que d'autres sont utilisés en masse et sont des plug-ins, justement.

Ça l'était.

Tu entends quoi par « pas fait pour » ? C'est des usages décrit par des différents standards tous très largement reconnus. Les serveurs sont développé avec ces usages en tête et les client aussi. Donc qu'est-ce qui n'est pas fait pour quoi ? Le fait que ça n'a pas était imaginé à la base ne l'empêche pas d'évoluer. Tu as vu la sécurité sur SMTP ou sur FTP, je trouve que HTTP et le web s'en sort pas si mal.

Dis-moi, c'est quoi, les websockets?

Un standard IETF pour le protocole, W3C pour l'API qui permet d'établir une communication bidirection avec HTTP. Au lieu d'avoir juste de requête/réponse, on maintiens la connexion (ce qui est déjà le cas au niveau TCP) et on permet le fullduplexe. Mais il n'est pas seul, tu as les server side event qui sont arrivés avec HTML5 (donc W3C) et l'IETF avec HTTP2 a créé le concept de server push.

Tout ces trucs là cherchent à remplacer des techniques comme le (long) polling. Quand il y a une pratique aussi répandu et autant de gens qui cherchent à y répondre c'est qu'il y a un besoin réel AMHA.