Je ne comprends pas grand chose à ton test. Des stats que tu montre il est le plus rapide des 3 pour aller voir ce qui se passe sur perdu.com
Oui, quand je n'avais fait que ce test, je pensais aussi que c'était lui le mieux.
mais sur tout ton test est presque plus proche d'un benchmark de webkit qu'autre chose
Non, puisqu'ils dépendent tous de la même version de webkit. Et puis, midori est bien plus rapide que n'importe lequel d'entre eux.
Je crois que la différence réside dans le fait que le téléchargement des données soit plus long. En fait, j'avoue ne pas savoir le pourquoi du comment: je n'ai pas profilé les binaires, mais en même temps, je ne meurs pas d'envie de comprendre pourquoi l'un est plus lent que l'autre. Ce qui m'intéresse, c'est que l'un est le plus rapide. Point barre.
Si j'ai déjà besoin de plus de 10 secondes pour afficher un truc aussi con que perdu.com (au passage désolé pour le formatage, j'ai toujours du mal a penser que linuxfr interprète ce qui est renvoyé par ma console. Je corrigerai bien, mais malheureusement c'est trop tard :/ ), il y a un sacré souci.
C'est effectivement proche d'un benchmark, à ceci près que je ne suis pas un robot et ait un temps de latence ;) mais pas de webkit: des couches logicielles qui l'exploitent, plutôt.
Tu parle de ce que tu a l'habitude de faire, mais je doute que tu surf en lançant un navigateur pour acchicher une url pour le fermer derrière (je ne dis pas que ça n'arrive pas juste que ça ne correspond pas à ce que l'on appel du surf (pas de suivi de lien, d'historique, de gestion des favoris, de téléchargement, etc).
En effet, ce petit test simple ne représente pas l'entièreté de mon usage internet. Cependant, si des outils ne sont même pas capables d'afficher perdu.com en moins de 5s, ils sont difficilement considérables comme exploitables sur le net. Il reste donc l'affichage de documentation locale, que je fais effectivement généralement en saisissant l'url complète sur la ligne de commande.
Pour les liens local c'est un problème connu, il y a un patch pour ça (c'est des navigateurs de barbus faut se plonger dans le code/la configuration), sinon ça marche quand tu lui donne une url (file://).
Après un nouvel essai avec le préfixe, j'ai:
$ time surf file:///usr/share/doc/libsdl1.2-dev/docs.html
(surf:8325): libsoup-WARNING **: No feature manager for feature of type 'SoupCookie'
real 0m0.466s
user 0m0.208s
sys 0m0.080s
C'est donc 2 fois plus rapide que luakit, mais bon... devoir taper file:// à chaque fois, c'est gênant.
Pour le suivi des liens, en local, je ne vois aucune différence. A l'usage pour une recherche google, avec des installations par défaut dans une Debian, qui fournit en général des configurations par défaut utilisables, on se tape largement plus de 15s après le clic que le bouton de recherche. J'aurai volontiers accusé JS, mais seul luakit semble l'activer par défaut. Et il est nettement plus rapide a chercher un truc.
Tu m'étonnes que c'est des trucs de barbu: le temps qu'ils affichent la moindre page, tu as une barbe de 3 jours qui a le temps pousser.
Ah, un nouveau détail fun: avec surf, encore et toujours, aller sur www.duckduckgo.com affiche le code de la page. Pas la page, non, juste le code. Youpi. Sur ce site, uzbl n'affiche que la moitié des choses, et encore une fois luakit gagne haut la main en affichant correctement les choses. Il prend son temps, mais il marche.
Je ne parlerai pas du fait que surf ne respecte pas la gestion des fenêtres: il affiche la barre d'URL sur toute la largeur de l'écran, et non de sa fenêtre personnelle. Très mauvais point ça. Idem pour ses raccourcis (mais ça, ça dois être configurable) en CTRL+truc. Genre CTRL+g pour ouvrir une URL, c'est quand même tout sauf intuitif. uzbl et luakit ici sont plus malins, un simple "o" suffit. "o" comme ouvrir/open, ce qui est utilisé partout depuis que je connais l'informatique ( même sous dos, on avait alt+f pour le menu fichier, puis o pour ouvrir... ). J'imagine que le "g" sers pour go, mais bon...
Je veux bien être barbu, mais il y a des limites, sinon j'utiliserai directement wget et un script perl fait main en guise de navigateur.
Surf est, définitivement, le pire (quel âge à le patch? Si c'est plus d'un mois, il me semble difficilement admissible qu'il ne sois pas encore mergé...). Et je n'ai plus l'intention de me faire chier à trouver des excuses aux mauvais logiciels, catégorie à laquelle ils appartiennent tous les 3. J'ai perdu assez de temps. Être libre et ne faire qu'une seule chose mais bien, ne vaut rien si c'est trop long.
Non, si je veux prêcher pour un navigateur utilisable et léger, je reste pour le moment sur midori ou opera. Dillo, à la rigueur, bien qu'il ne supporte que le html pur et dur (pas d'images, ni de script, ni de style donc, on dirait. Mais au moins c'est rapide. Je crois que je vais l'adopter d'ailleurs, pour les doc techniques...).
[^] # Re: Intérêt
Posté par freem . En réponse à la dépêche Haiku est vivant. Évalué à 0.
Oui, quand je n'avais fait que ce test, je pensais aussi que c'était lui le mieux.
Non, puisqu'ils dépendent tous de la même version de webkit. Et puis, midori est bien plus rapide que n'importe lequel d'entre eux.
Je crois que la différence réside dans le fait que le téléchargement des données soit plus long. En fait, j'avoue ne pas savoir le pourquoi du comment: je n'ai pas profilé les binaires, mais en même temps, je ne meurs pas d'envie de comprendre pourquoi l'un est plus lent que l'autre. Ce qui m'intéresse, c'est que l'un est le plus rapide. Point barre.
Si j'ai déjà besoin de plus de 10 secondes pour afficher un truc aussi con que perdu.com (au passage désolé pour le formatage, j'ai toujours du mal a penser que linuxfr interprète ce qui est renvoyé par ma console. Je corrigerai bien, mais malheureusement c'est trop tard :/ ), il y a un sacré souci.
C'est effectivement proche d'un benchmark, à ceci près que je ne suis pas un robot et ait un temps de latence ;) mais pas de webkit: des couches logicielles qui l'exploitent, plutôt.
En effet, ce petit test simple ne représente pas l'entièreté de mon usage internet. Cependant, si des outils ne sont même pas capables d'afficher perdu.com en moins de 5s, ils sont difficilement considérables comme exploitables sur le net. Il reste donc l'affichage de documentation locale, que je fais effectivement généralement en saisissant l'url complète sur la ligne de commande.
Après un nouvel essai avec le préfixe, j'ai:
C'est donc 2 fois plus rapide que luakit, mais bon... devoir taper file:// à chaque fois, c'est gênant.
Pour le suivi des liens, en local, je ne vois aucune différence. A l'usage pour une recherche google, avec des installations par défaut dans une Debian, qui fournit en général des configurations par défaut utilisables, on se tape largement plus de 15s après le clic que le bouton de recherche. J'aurai volontiers accusé JS, mais seul luakit semble l'activer par défaut. Et il est nettement plus rapide a chercher un truc.
Tu m'étonnes que c'est des trucs de barbu: le temps qu'ils affichent la moindre page, tu as une barbe de 3 jours qui a le temps pousser.
Ah, un nouveau détail fun: avec surf, encore et toujours, aller sur www.duckduckgo.com affiche le code de la page. Pas la page, non, juste le code. Youpi. Sur ce site, uzbl n'affiche que la moitié des choses, et encore une fois luakit gagne haut la main en affichant correctement les choses. Il prend son temps, mais il marche.
Je ne parlerai pas du fait que surf ne respecte pas la gestion des fenêtres: il affiche la barre d'URL sur toute la largeur de l'écran, et non de sa fenêtre personnelle. Très mauvais point ça. Idem pour ses raccourcis (mais ça, ça dois être configurable) en CTRL+truc. Genre CTRL+g pour ouvrir une URL, c'est quand même tout sauf intuitif. uzbl et luakit ici sont plus malins, un simple "o" suffit. "o" comme ouvrir/open, ce qui est utilisé partout depuis que je connais l'informatique ( même sous dos, on avait alt+f pour le menu fichier, puis o pour ouvrir... ). J'imagine que le "g" sers pour go, mais bon...
Je veux bien être barbu, mais il y a des limites, sinon j'utiliserai directement wget et un script perl fait main en guise de navigateur.
Surf est, définitivement, le pire (quel âge à le patch? Si c'est plus d'un mois, il me semble difficilement admissible qu'il ne sois pas encore mergé...). Et je n'ai plus l'intention de me faire chier à trouver des excuses aux mauvais logiciels, catégorie à laquelle ils appartiennent tous les 3. J'ai perdu assez de temps. Être libre et ne faire qu'une seule chose mais bien, ne vaut rien si c'est trop long.
Non, si je veux prêcher pour un navigateur utilisable et léger, je reste pour le moment sur midori ou opera. Dillo, à la rigueur, bien qu'il ne supporte que le html pur et dur (pas d'images, ni de script, ni de style donc, on dirait. Mais au moins c'est rapide. Je crois que je vais l'adopter d'ailleurs, pour les doc techniques...).