Tu fais bien de parler de jugement vu la suite de ton commentaire...
N'est-ce pas? :)
c'est tout de même bien tranché tu ne trouve pas ?
Si. Mais, si ça me permets de lever le débat, quitte à avoir tort et le reconnaître en public, ça vaut le coup (en même temps, même si j'y tiens, ce n'est que mon identité de geek, tu me diras).
Notes, je ne reconnais pas encore avoir tort sur la totalité (hé, si je m'éclate sur linuxfr, c'est bien parce que l'on peut trouver des gens pour débattre et nous convaincre quand on se plante).
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.
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)...
C'est simple une fonctionnalité existante est mieux qu'une fonctionnalité théorique.
Totalement vrai. Je te citerais peut-être, si d'une part tu me le permets (très probable), et d'autre part je m'en souviens (peu probable).
Effectivement c'est selon toi donc pas la peine de commencer en étant aussi tranché :)
Heh. +1.
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).
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.
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?
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).
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?
Bon, j'avoue, sur le dernier point, c'est un fantasme de ma part que je n'ai vu nulle part, mais je pense que mon niveau de confiance dans un brouteur qui fait ça augmenterait sensiblement, et serait pour moi un vrai argument d'usage. Bon, clairement, ça ne parlera jamais à Mme Michu... Mais, Firefox, leur pub initiale, ça a été les geeks, pas doubleclick.com.
quant à la performance
Bon, sur la perf, je me couche aussi, il faut dire que c'est dire complexe: une recherche à chaud ou à froid? Sur un SSH ou HDD? IL y a des chances que le choix d'un SGBDR soit justement pour la perf à froid sur un HDD monolithique (sur un fichier non fragmenté ou à faible fragmentation, les performances à priori approchent celles d'un SSD, et un SGBDR sera traditionnellement prévu pour... ce qui me fait penser que c'est p'tet juste un workaround? D'ailleurs, je me demande, ça donne quoi sur des SSD?)
Mettre à disposition des gens de quoi devenir acteur du web et comprendre/maitriser ce qu'ils ont devant eux ne me paraît pas choquant.
Je n'ai pas dis que ça me choquait. Ce que je mettais en doute ici, c'est le fait de mettre ça en exergue comme une fonctionnalité importante.
Soyons honnêtes: si tu veux faire adopter le panda roux, tu ne mettras quand même pas ça en exergue, si?
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.
Je trouve que ça fait tâche.
Que ce soir l'un ou l'autre ils ont pété une fois la compatibilité en 15 ans, c'est ce que tu appel « ne pas arrêter de casser » ?
Ok, je te l'accorde, il s'agit ici d'une impression globale, tirée de diverses lectures. En gros, de l'image qu'ils me renvoient, en tant que développeur, pas web mais surtout Freem.
Comme toutes les images, elles peut être erronnée.
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?
Pourquoi ne pas utiliser uzbl ou surf ? Ils font juste ce que tu semble attendre d'un navigateur.
Dans le cas d'uzbl, parce qu'il porte très mal son nom. Pour surf, je pense l'avoir essayé, mais je ne me souviens pas, tu fais très bien de me rappeller son existence.
[^] # Re: Opera v5?
Posté par freem . En réponse au journal De la publicité dans Firefox (sur un air de déjà vu). Évalué à 2.
N'est-ce pas? :)
Si. Mais, si ça me permets de lever le débat, quitte à avoir tort et le reconnaître en public, ça vaut le coup (en même temps, même si j'y tiens, ce n'est que mon identité de geek, tu me diras).
Notes, je ne reconnais pas encore avoir tort sur la totalité (hé, si je m'éclate sur linuxfr, c'est bien parce que l'on peut trouver des gens pour débattre et nous convaincre quand on se plante).
À 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.
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)...
Totalement vrai. Je te citerais peut-être, si d'une part tu me le permets (très probable), et d'autre part je m'en souviens (peu probable).
Heh. +1.
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).
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 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?
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).
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?
Bon, j'avoue, sur le dernier point, c'est un fantasme de ma part que je n'ai vu nulle part, mais je pense que mon niveau de confiance dans un brouteur qui fait ça augmenterait sensiblement, et serait pour moi un vrai argument d'usage. Bon, clairement, ça ne parlera jamais à Mme Michu... Mais, Firefox, leur pub initiale, ça a été les geeks, pas doubleclick.com.
Bon, sur la perf, je me couche aussi, il faut dire que c'est dire complexe: une recherche à chaud ou à froid? Sur un SSH ou HDD? IL y a des chances que le choix d'un SGBDR soit justement pour la perf à froid sur un HDD monolithique (sur un fichier non fragmenté ou à faible fragmentation, les performances à priori approchent celles d'un SSD, et un SGBDR sera traditionnellement prévu pour... ce qui me fait penser que c'est p'tet juste un workaround? D'ailleurs, je me demande, ça donne quoi sur des SSD?)
Je n'ai pas dis que ça me choquait. Ce que je mettais en doute ici, c'est le fait de mettre ça en exergue comme une fonctionnalité importante.
Soyons honnêtes: si tu veux faire adopter le panda roux, tu ne mettras quand même pas ça en exergue, si?
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.
Je trouve que ça fait tâche.
Ok, je te l'accorde, il s'agit ici d'une impression globale, tirée de diverses lectures. En gros, de l'image qu'ils me renvoient, en tant que développeur, pas web mais surtout Freem.
Comme toutes les images, elles peut être erronnée.
Dis-moi, c'est quoi, les websockets?
Dans le cas d'uzbl, parce qu'il porte très mal son nom. Pour surf, je pense l'avoir essayé, mais je ne me souviens pas, tu fais très bien de me rappeller son existence.