L'argument de la fibre jusqu'au répartiteur ne vaut rien, parce qu'à ce compte-là, l'ADSL aussi c'est de la fibre, jusqu'au DSLAM.
Sauf qu'en théorie tu pourrait avoir du VDSL sur le coaxial (100Mb symétrique à 300m pour VDSL2), mais bon la page wikipedia sur VDSL ne donne pas beaucoup d'espoir sur le sujet en France..
il y a plein d'applications qui peuvent prendre des screenshots et qui sont très utiles.
Et il y a des applications qui cherchent a récupérer plein d'information qu'elles ne devraient pas pouvoir avoir.
Tu peux te logger sous root et autoriser tous les droits si tu n'en as rien a faire de la sécurité, le problème c'est que quelqu'un qui lui est concerné par la sécurité ne peut pas vraiment installer une application avec X à moins d'utiliser une usine à gaz genre Qubes OS.
Ceci explique en quoi le brevet logiciel en Europe ne fonctionne pas, le brevet protégerait le code source et qui serait publié.
Je n'ai jamais vu de code source dans un brevet, dans un brevet on trouve en général des algorithmes!
Et "le brevet logiciel en Europe ne fonctionne pas"? Vraiment? Pourtant il me semble avoir vu à quelques reprise des condamnation à ce sujet en Allemagne.
J'ai arrêté de lire là, avec la forte impression qu'il s'agit encore d'un texte foireux sur ce sujet..
C'est là que Gnome devrait placer la barre pour conquérir les débutants.
Bah déjà il y a un problème de buts, dois t'on essayer de conquérir les débutants ou les habitués de Windows?
L'interface n'est pas là même pour les 2, à priori il faut donc 2 configuration différentes (au moins, il y a le Mac aussi).
Avoir besoin d'un bouton "Alt" pour accéder à une fonction basique, pour un débutant, c'est déjà rédhibitoire. Le fait qu'il soit impossible à un dev Gnome de comprendre ça me convainc déjà que c'est une cause perdue pour les grands débutants.
Note que les devs de WindowsXP ont fait la même erreur: qui connait "Shift + Click droit"?
Comme quoi les professionnel font aussi des grosses bêtises, mais je te rejoins: faire une erreur ça n'est pas le problème, mais avoir du mal a corriger son erreur quand on la fait remarquer là c'est un vrai problème.
Dans les cas usuels, ça ne devrai pas être le cas. Moi quand je change mes routes, tout le cache est déjà flushé par le noyau.
C'est vieux ce dont je parles: noyau 2.4 et j'essayai de baisser à quelques ms le temps de basculement et le timer entre 2 flush du cache des routes étaient à 20ms par défaut (de mémoire), donc un utilisateur 'normal' ne s'en apercevrait pas.
Une fois que tu comprends le mécanisme pas de problème, mais coté documentation c'était (c'est?) assez pauvre.
Et le problème que j'ai quand je veux changer des routes, c'est plutôt que tout les paquets dans la file de la première interface partent dans /dev/null. TCP s'en fout, mais pas le reste …
Comprends pas là? Les pertes de paquets ça arrive, lors d'un changement de route ou autre, donc de toute manière il faut bien un mécanisme de reprise soit fourni par la couche réseau TCP/SCTP soit à faire soit même (le reste).
Gambas est typé statiquement, sauf qu'il possède le type Variant, qui peut contenir n'importe quel type, ainsi que le type Object, qui peut contenir n'importe quel type d'objet.
Le "sauf que" est peut-être en trop: Scala a Any et Object mais on le considère quand même comme typé statiquement..
Pour résumer, je dirais donc que Gambas à l'air d'être typé statiquement, mais qu'à l'intérieur il est pratiquement typé dynamiquement.
Pas sûr de comprendre, même si l'implémentation se base sur du typage dynamique, si ça n'apporte pas le comportement d'un langage dynamique, c'est un langage à typage statique point.
Weston does not yet support screen-shot applications
Je crois que c'est le mot application là qui est important, mais après j'ai du mal avec la doc et Wayland/Weston..
Il n'y a pas si longtemps j'ai découvert que j'avais fait une erreur grossière concernant Weston: je croyais que déplacer une fenetre était fait par l'application (à chaque déplacement de souris l'application reçoit un évènement et dis à Weston "déplace moi") et bien non, l'application dit à Weston quand elle reçoit un clic sur le titre "je suis en mode déplacement" et ensuite c'est Weston qui fait le boulot..
Beaucoup mieux au niveau réactivité!
Gambas est-il typé statiquement ou dynamiquement?
D'après les exemples que tu donne, cela ressemble plutôt à du typage statique donc la comparaison devrait plutôt être vis à vis de Java, non?
Intéressant: si on ajoute ça a la mise en sommeil hybride: c'est encore plus intéressant: moins de risque que l'ordinateur surchauffe en cas de problème pour passer de la veille à l’hibernation (puisque l'hibernation est fait au début).
Euh comprends pas là, ce texte justifie la remarque de Christophe Merlet, si tu mets en hibernation, tu préserve la durée de vie de ta batterie car ce sera une recharge partielle, quand tu garde ton ordinateur en veuille et que la batterie se décharge totalement (cas anticipé par l'hibernation et veille combinée) et bien c'est une recharge complète donc pas bon pour ce type de batterie.
Donc je suis d'accord avec lui: l'hibernation et veille combinée ça encourage la mise en veille jusqu'à décharge totale de la batterie ce qui n'est pas bon pour la batterie.
L'idéal: hibernation + SSD: ça poutre et ça préserve la durée de vie de la batterie.
Je me souviens d'un projet où on voulait avoir le basculement le plus rapide possible d'une interface à l'autre en cas de panne et il y avait un problème: on change les route et là .. rien: les paquets sont toujours émis sur la mauvaise interface, après avoir chercher dans pas mal de direction, le coupable était en fait le cache de routage.
Contournement du problème: "flusher" le cache de routage.
Dommage que je ne sois plus sur ce projet: je me demande la durée de prise en compte d'un changement de route avec ce nouveau code.
Oups, j'ai l'impression que j'ai mal compris le protocole pour ce qui est de déplacer une fenetre: apparemment c'est fait dans le serveur d'affichage pas dans le client, le client dits juste 'maintenant déplace la fenetre' et le serveur déplace la fenetre jusqu'à ce que le pointeur soit relaché!
Très sympa pour la transparence réseau en fait.
Bon le redimensionnement là je ne suis pas sûr.. Ca manque de documentation je trouve..
Bof, c'est normal l'utilisateur voudra lire ce genre de chose quand il rencontre une difficulté, pas au début.
Ce qui est pour ça que je trouve que les logiciels qui mettent une fenêtre "voici comment utiliser ce logiciel" sans moyen simple de rappeler la fenêtre plus tard sont mal conçus.
Pas que je sache, maintenant ça a quand même des impacts assez intéressant: avec KWin déplacer une fenetre pourra se faire uniquement dans le serveur d'affichage(car il incluera le gestionnaire de fenetre), avec Weston il y a des communications avec le programme (qui envoit les ordres de déplacement)..
Wayland n'aucune influence sur les performances (en bien ou en mal) par rapport à X?
Non, aucune.
Je ne dirais pas "aucune", Wayland en lui-même c'est l'équivalent de DRI2 d'un serveur X donc pas d'impact.
Mais Wayland avec Weston intégre une partie de la gestion des fenetres dans les clients (les devs KDE ont prévu un choix différent) ce qui a des conséquences sur la performance vue par le client, en bien ET en mal d'ailleurs.
C'est faux, un ssh -CX est bien mieux qu'un ssh -X, idem NX est super bien…
NX ne fait pas que compresser les données, il minimise aussi le nombre de RTT donc tu ne peux pas dire que c'est uniquement une affaire de débit.
Plus je vois le projet Wayland, plus j'entends qu'au final, ce ne sera pas mieux que X…
Ce sera mieux pour les mainteneurs du code car ça fait beaucoup moins de chose donc ça devrait être plus facile à maintenir.
Pour les utilisateurs, pas sûr en effet, il y a certains avantages mais il y a aussi des inconvénients.
Coté bande passante, ce sont des buffers entiers qui sont envoyé.
Après il est envisageable de n'envoyer que le delta par rapport au buffer précédent.
Donc coté utilisation de bande passante, Wayland natif ne sera pas très bon, mais le débit des connections augmentant régulièrement ce n'est pas sûr que ce soit un problème.
La question principale est donc la latence, Kristian Høgsberg dit qu'il a essayé de minimiser le nombre de round trip, mais dit aussi qu'il n'a pas testé la transparence en simulant une latence élevée, dommage, j'espère qu'il le fera avant de figer Wayland(la version 1.0).
Avec Weston qui fait gérer le bord des fenêtres par le client, déplacer une fenêtre nécessite un round trip, mais tous les serveurs Wayland n'utiliseront pas forcément la même conception que Weston n'est pas le seul serveur possible: les devs de KDE prévoient de mettre cette aspect là dans le serveur, ce qui est mieux en distant (mais peut avoir d'autre inconvénients).
OK, mais la question est: pour quelle raison changer de nom?
Parce que les gens trouvent ce nom moche (par exemple)?
OK, ça serait une raison correcte.
Parce que ça défrise la religion machin?
Pas d'accord!
Après tout, si ça les embêtent tant que ça, les Chrétiens peuvent changer le nom qu'ils utilisent eux.
D'ailleurs je ne vois pas pourquoi les Chrétiens ne peuvent pas marier des gens non mariés civilement.
Posté par reno .
En réponse au journal Gros bras.
Évalué à 1.
Dis, si tu faisais l'effort de google le texte que j'ai donnée, tu verrais que le premier résultat est un papier pour Javascript.
Voila le lien: http://www.cs.utexas.edu/~mckinley/papers/pjit-pespma-2009.pdf
puisque tu es un fainéant voila la conclusion:
"In this paper, we showed that even though JavaScript language itself is currently single-threaded, both its throughput and responsiveness can benefit from multiple cores with our concurrent JIT compiler. This improvement is achieved by running the JIT compiler concurrently with the interpreter. Our results show that most of the compile-time pauses can be eliminated, resulting in a total, average, and maximum reduction in pause time by 89%, 97%, and 93%, respectively. Moreover, the throughput is also increased by an average of 6%, with a maximum of 34%. This paper demonstrates a way to exploit multicore hardware to improve application performance and responsiveness by offloading system tasks"
[^] # Re: Je ne vais pas le pleurer le cache de routage..
Posté par reno . En réponse à la dépêche Sortie du noyau Linux 3.6. Évalué à 3.
Pour le multijoueur ok, pour la voip je dirais que ça dépend beaucoup du nombre de paquets perdus, le trou peut être quasiment inaudible..
[^] # Re: reponse partielle
Posté par reno . En réponse au message Kikala Fibre Optique ?. Évalué à 3.
Sauf qu'en théorie tu pourrait avoir du VDSL sur le coaxial (100Mb symétrique à 300m pour VDSL2), mais bon la page wikipedia sur VDSL ne donne pas beaucoup d'espoir sur le sujet en France..
[^] # Re: noop
Posté par reno . En réponse au journal Un article sur la conception sécurisée des serveurs graphiques (X, Wayland). Évalué à 3.
Et il y a des applications qui cherchent a récupérer plein d'information qu'elles ne devraient pas pouvoir avoir.
Tu peux te logger sous root et autoriser tous les droits si tu n'en as rien a faire de la sécurité, le problème c'est que quelqu'un qui lui est concerné par la sécurité ne peut pas vraiment installer une application avec X à moins d'utiliser une usine à gaz genre Qubes OS.
# Très surpris
Posté par reno . En réponse à la dépêche Un bilan de la guerre des brevets des télécommunications (de 2007 à aujourd’hui). Évalué à 4.
Une partie du texte:
Je n'ai jamais vu de code source dans un brevet, dans un brevet on trouve en général des algorithmes!
Et "le brevet logiciel en Europe ne fonctionne pas"? Vraiment? Pourtant il me semble avoir vu à quelques reprise des condamnation à ce sujet en Allemagne.
J'ai arrêté de lire là, avec la forte impression qu'il s'agit encore d'un texte foireux sur ce sujet..
[^] # Re: Stratégiquement bancal!
Posté par reno . En réponse au journal Interview de Vincent Untz, développeur GNOME. Évalué à 2.
Bah déjà il y a un problème de buts, dois t'on essayer de conquérir les débutants ou les habitués de Windows?
L'interface n'est pas là même pour les 2, à priori il faut donc 2 configuration différentes (au moins, il y a le Mac aussi).
Note que les devs de WindowsXP ont fait la même erreur: qui connait "Shift + Click droit"?
Comme quoi les professionnel font aussi des grosses bêtises, mais je te rejoins: faire une erreur ça n'est pas le problème, mais avoir du mal a corriger son erreur quand on la fait remarquer là c'est un vrai problème.
[^] # Re: Stratégiquement bancal!
Posté par reno . En réponse au journal Interview de Vincent Untz, développeur GNOME. Évalué à 3.
Et bien ils le font:
http://people.gnome.org/~federico/news-2012-09.html#uo-hackfest-1
Je ne défends pas vraiment Gnome, mais le YaQu'aFautQu'on c'est un peu facile aussi.
[^] # Re: Je ne vais pas le pleurer le cache de routage..
Posté par reno . En réponse à la dépêche Sortie du noyau Linux 3.6. Évalué à 1.
C'est vieux ce dont je parles: noyau 2.4 et j'essayai de baisser à quelques ms le temps de basculement et le timer entre 2 flush du cache des routes étaient à 20ms par défaut (de mémoire), donc un utilisateur 'normal' ne s'en apercevrait pas.
Une fois que tu comprends le mécanisme pas de problème, mais coté documentation c'était (c'est?) assez pauvre.
Comprends pas là? Les pertes de paquets ça arrive, lors d'un changement de route ou autre, donc de toute manière il faut bien un mécanisme de reprise soit fourni par la couche réseau TCP/SCTP soit à faire soit même (le reste).
[^] # Re: Sockets Unix
Posté par reno . En réponse à la dépêche Sortie du noyau Linux 3.6. Évalué à 5.
Quand tu vois qu'ils font aussi des optimisations pour 4096 processeurs, tu te dis qu'il y a des p…. d'ordinateurs qui font tourner Linux..
[^] # Re: Typage statique ou dynamique?
Posté par reno . En réponse à la dépêche Sortie de Gambas 3.3. Évalué à 3.
Le "sauf que" est peut-être en trop: Scala a Any et Object mais on le considère quand même comme typé statiquement..
Pas sûr de comprendre, même si l'implémentation se base sur du typage dynamique, si ça n'apporte pas le comportement d'un langage dynamique, c'est un langage à typage statique point.
[^] # Re: noop
Posté par reno . En réponse au journal Un article sur la conception sécurisée des serveurs graphiques (X, Wayland). Évalué à 3.
Je crois que c'est le mot application là qui est important, mais après j'ai du mal avec la doc et Wayland/Weston..
Il n'y a pas si longtemps j'ai découvert que j'avais fait une erreur grossière concernant Weston: je croyais que déplacer une fenetre était fait par l'application (à chaque déplacement de souris l'application reçoit un évènement et dis à Weston "déplace moi") et bien non, l'application dit à Weston quand elle reçoit un clic sur le titre "je suis en mode déplacement" et ensuite c'est Weston qui fait le boulot..
Beaucoup mieux au niveau réactivité!
# Typage statique ou dynamique?
Posté par reno . En réponse à la dépêche Sortie de Gambas 3.3. Évalué à 2.
Gambas est-il typé statiquement ou dynamiquement?
D'après les exemples que tu donne, cela ressemble plutôt à du typage statique donc la comparaison devrait plutôt être vis à vis de Java, non?
PS: Intéressant tes coups de gueules.
[^] # Re: Merci pour la news
Posté par reno . En réponse à la dépêche Sortie du noyau Linux 3.6. Évalué à 3.
Intéressant: si on ajoute ça a la mise en sommeil hybride: c'est encore plus intéressant: moins de risque que l'ordinateur surchauffe en cas de problème pour passer de la veille à l’hibernation (puisque l'hibernation est fait au début).
[^] # Re: Merci pour la news
Posté par reno . En réponse à la dépêche Sortie du noyau Linux 3.6. Évalué à 4.
Euh comprends pas là, ce texte justifie la remarque de Christophe Merlet, si tu mets en hibernation, tu préserve la durée de vie de ta batterie car ce sera une recharge partielle, quand tu garde ton ordinateur en veuille et que la batterie se décharge totalement (cas anticipé par l'hibernation et veille combinée) et bien c'est une recharge complète donc pas bon pour ce type de batterie.
Donc je suis d'accord avec lui: l'hibernation et veille combinée ça encourage la mise en veille jusqu'à décharge totale de la batterie ce qui n'est pas bon pour la batterie.
L'idéal: hibernation + SSD: ça poutre et ça préserve la durée de vie de la batterie.
# Je ne vais pas le pleurer le cache de routage..
Posté par reno . En réponse à la dépêche Sortie du noyau Linux 3.6. Évalué à 8.
Je me souviens d'un projet où on voulait avoir le basculement le plus rapide possible d'une interface à l'autre en cas de panne et il y avait un problème: on change les route et là .. rien: les paquets sont toujours émis sur la mauvaise interface, après avoir chercher dans pas mal de direction, le coupable était en fait le cache de routage.
Contournement du problème: "flusher" le cache de routage.
Dommage que je ne sois plus sur ce projet: je me demande la durée de prise en compte d'un changement de route avec ce nouveau code.
[^] # Re: Et concrètement ?
Posté par reno . En réponse au journal La transparence réseau arrive dans Wayland. Évalué à 2.
Oups, j'ai l'impression que j'ai mal compris le protocole pour ce qui est de déplacer une fenetre: apparemment c'est fait dans le serveur d'affichage pas dans le client, le client dits juste 'maintenant déplace la fenetre' et le serveur déplace la fenetre jusqu'à ce que le pointeur soit relaché!
Très sympa pour la transparence réseau en fait.
Bon le redimensionnement là je ne suis pas sûr.. Ca manque de documentation je trouve..
[^] # Re: nom des applications
Posté par reno . En réponse à la dépêche GNOME 3.6 : en route vers GNOME 4.0 !. Évalué à 5.
Bof, c'est normal l'utilisateur voudra lire ce genre de chose quand il rencontre une difficulté, pas au début.
Ce qui est pour ça que je trouve que les logiciels qui mettent une fenêtre "voici comment utiliser ce logiciel" sans moyen simple de rappeler la fenêtre plus tard sont mal conçus.
[^] # Re: Le faire, c'est mieux quand c'est possible...
Posté par reno . En réponse au journal Nouvel article de Bret Victor sur sa vision de l'environnement de développement du futur. Évalué à 4.
Après le problème c'est qu'on utilise rarement des nombres en dur et qu'avec des variables ça fait un peu redite non?
rect(x: foo_x, y: foo_y, width: foo_w, height:foo_h), ça n'apporte pas grand chose à la place de rect(foo_x, foo_y, foo_w, foo_h)
[^] # Re: Et concrètement ?
Posté par reno . En réponse au journal La transparence réseau arrive dans Wayland. Évalué à 3.
Pas que je sache, maintenant ça a quand même des impacts assez intéressant: avec KWin déplacer une fenetre pourra se faire uniquement dans le serveur d'affichage(car il incluera le gestionnaire de fenetre), avec Weston il y a des communications avec le programme (qui envoit les ordres de déplacement)..
[^] # Re: Le faire, c'est mieux quand c'est possible...
Posté par reno . En réponse au journal Nouvel article de Bret Victor sur sa vision de l'environnement de développement du futur. Évalué à 2.
Oui, dommage que beaucoup de langages ne supportent pas ce type d'appels de fonction, ça me parait quand même beaucoup plus lisible.
[^] # Re: Et concrètement ?
Posté par reno . En réponse au journal La transparence réseau arrive dans Wayland. Évalué à 2.
Je ne dirais pas "aucune", Wayland en lui-même c'est l'équivalent de DRI2 d'un serveur X donc pas d'impact.
Mais Wayland avec Weston intégre une partie de la gestion des fenetres dans les clients (les devs KDE ont prévu un choix différent) ce qui a des conséquences sur la performance vue par le client, en bien ET en mal d'ailleurs.
[^] # Re: Et concrètement ?
Posté par reno . En réponse au journal La transparence réseau arrive dans Wayland. Évalué à 3.
NX ne fait pas que compresser les données, il minimise aussi le nombre de RTT donc tu ne peux pas dire que c'est uniquement une affaire de débit.
Ce sera mieux pour les mainteneurs du code car ça fait beaucoup moins de chose donc ça devrait être plus facile à maintenir.
Pour les utilisateurs, pas sûr en effet, il y a certains avantages mais il y a aussi des inconvénients.
[^] # Re: Et concrètement ?
Posté par reno . En réponse au journal La transparence réseau arrive dans Wayland. Évalué à 3.
Coté bande passante, ce sont des buffers entiers qui sont envoyé.
Après il est envisageable de n'envoyer que le delta par rapport au buffer précédent.
Donc coté utilisation de bande passante, Wayland natif ne sera pas très bon, mais le débit des connections augmentant régulièrement ce n'est pas sûr que ce soit un problème.
La question principale est donc la latence, Kristian Høgsberg dit qu'il a essayé de minimiser le nombre de round trip, mais dit aussi qu'il n'a pas testé la transparence en simulant une latence élevée, dommage, j'espère qu'il le fera avant de figer Wayland(la version 1.0).
Avec Weston qui fait gérer le bord des fenêtres par le client, déplacer une fenêtre nécessite un round trip, mais tous les serveurs Wayland n'utiliseront pas forcément la même conception que Weston n'est pas le seul serveur possible: les devs de KDE prévoient de mettre cette aspect là dans le serveur, ce qui est mieux en distant (mais peut avoir d'autre inconvénients).
[^] # Re: Pour!
Posté par reno . En réponse au journal Le prophète et la liberté. Évalué à 2.
C'est débatable d'un point de vue historique, et ça n'a pas d'importance: le mariage civil existe aussi depuis longtemps..
[^] # Re: Pour!
Posté par reno . En réponse au journal Le prophète et la liberté. Évalué à 2.
OK, mais la question est: pour quelle raison changer de nom?
Parce que les gens trouvent ce nom moche (par exemple)?
OK, ça serait une raison correcte.
Parce que ça défrise la religion machin?
Pas d'accord!
Après tout, si ça les embêtent tant que ça, les Chrétiens peuvent changer le nom qu'ils utilisent eux.
D'ailleurs je ne vois pas pourquoi les Chrétiens ne peuvent pas marier des gens non mariés civilement.
[^] # Re: Qui aurait cru...
Posté par reno . En réponse au journal Gros bras. Évalué à 1.
Dis, si tu faisais l'effort de google le texte que j'ai donnée, tu verrais que le premier résultat est un papier pour Javascript.
Voila le lien:
http://www.cs.utexas.edu/~mckinley/papers/pjit-pespma-2009.pdf
puisque tu es un fainéant voila la conclusion:
"In this paper, we showed that even though JavaScript language itself is currently single-threaded, both its throughput and responsiveness can benefit from multiple cores with our concurrent JIT compiler. This improvement is achieved by running the JIT compiler concurrently with the interpreter. Our results show that most of the compile-time pauses can be eliminated, resulting in a total, average, and maximum reduction in pause time by 89%, 97%, and 93%, respectively. Moreover, the throughput is also increased by an average of 6%, with a maximum of 34%. This paper demonstrates a way to exploit multicore hardware to improve application performance and responsiveness by offloading system tasks"
Pied --> bouche ++