Maiiiiiiis non !
Nos députés savent bien que si la vie privé d'un pauvre terroriste en puissancecitoyen ne vaut pas grand chose, les entreprises au contraire doivent être défendues.
Par exemple dans la loi sur la riposte graduée, la coupure de l'accès internet n'est possible que pour les personnes physiques, pas pour les entreprises (et encore moins pour l'état.)
Je ne connais pas du tout le fonctionnement des cartes physiques. En quoi diffèrent-elles d'une carte graphique ?
Il me semblerait logique que les deux se prêtent au parallélisme massif ... J'ai même cru entendre qu'elles arrivaient trop tard (les cartes physiques) et qu'avec les cartes graphiques programmables, leur valeur ajoutée était ridicule.
Je pense de mon côté que la révolution (si révolution il y a) viendra des langages interprétés et JITés. Je ne serais pas étonné qu'on nous refasse le coup du Out-of-order_execution avec le bytecode dans le rôle de l'assembleur et l'assembleur dans le rôle du microcode.
Je m'explique : le OoO revient à transformer l'assembleur du binaire en un code plus finement découpé : le microcode. Ce microcode est stocké dans un "pool" dans le processeur et chaque instruction est exécutée dans le désordre (out of order) dès que ses dépendances sont satisfaites.
Une partie du processeur est donc destinée à la gestion de ce mécanisme : traduction, gestion des dépendances, etc ...
Dans le cas du bytecode, on ajoute une étape de transformation. Le bytecode est soit interprété, soit transformé en code assembleur pendant l'exécution (JIT). Il me semble que cette étape ressemble fortement à ce qui se fait pour le OoO, mais à une échelle plus large.
On pourrait donc imaginer une architecture où un coeur est destiné à la gestion de ce bytecode (exécution de la VM) et où les autres coeurs exécutent le résultat. Cette solution permettrait de tirer partie de coeurs hétérogènes : 1CPU OoO classique pour l'interprétation, un GPU pour ce qui se parallélise facilement, un VLIW pour ce qui a été JITé, un FPGA pour les tâches très répétitives, etc ...
> La dépêche a faire l'erreur, et maintenance c'est un commentaire.
Dans la suite de ma réponse, je considèrerai que tu as voulu dire «La dépêche a fait l'erreur, et maintenant c'est un commentaire.» Si je me trompe, merci de l'ignorer.
J'imagine que tu dis ça en référence au troll pour savoir si avec son préprocesseur, Qt est une bibliothèque ou un langage. Ne revenons pas dessus, on sait tous qu'il n'y a pas de point de vue qui fasse consensus ici.
Considérons donc comme tu le fais que Qt est une bibliothèque, non un langage.
Je ne comprend pas en quoi cette formulation est une erreur. Certes le code est en C ou en C++ mais le résultat, l'application, est un binaire. Et l'exécution de ce binaire donne une interface en GTK ou en Qt. J'ai toujours entendu cette formulation ...
En plus de ça, dans la dépèche, il est écrit «Développé avec QT4 et les librairies mises à disposition par le projet KDE» quelle autre formulation adopter ? Il me semble que parler d'une application développée avec C ou avec C++ ne voudrait pas dire grand chose ...
Bref, je ne comprend pas la remarque. J'ai l'impression qu'à force de chercher la pureté du langage, on en vient à ne plus accepter des choses tout à fait correctes sur ce site.
C'est parce que la langue est malléable qu'on a eu de grands auteurs qui ont sû en jouer. Ce n'est pas en créant une novlang codifiée et figée qu'on se comprendra mieux.
Non, je voulais plutôt dire qu'il y a aussi debian, gentoo, etc ... et que je trouve que ce sont des distributions tout aussi "évoluées" qu'opensuse ou ubuntu.
Elles ont juste des buts et des points forts différents.
> Je l'ai dit qu'une fois. Mais t'as raison.
> M'enfin, c'est limite un coup de chance.
Je crois que ces deux lignes suffisent à appréhender la suffisance du personnage.
Surtout après avoir passé une page de commentaires à détruire le mainteneur debian, parce qu'il a fait une erreur et c'est impardonnable et ça arriverait pas chez ...
Me semble que le Jérome K a justement été viré ....
Eheh, non, il me semble au contraire qu'il est aussi difficile de se faire virer de la SG que de debian ;)
Pour la petite histoire, je crois qu'il était spécifié dans le contrat de Jérôme K. qu'un renvoi doit être précédé par un entretient avec sa hiérarchie ... Oui, sauf qu'il a justement l'interdiction légale d'avoir des contacts avec sa hiérarchie ou toute autre personne liée à l'affaire pendant l'enquête.
Oui, tu as raison, je me suis mal exprimé et je dis des bêtises du coup.
Le vrai argument ici, c'est que dans ce cas, l'espace utilisé par le code est négligeable par rapport à celui utilisé par les donnés.
Je n'ai pas de chiffre sous les yeux, mais je ne serais pas étonné que l'espace utilisé par le code de KHTML en mémoire soit inférieur d'au moins un ordre de grandeur à ce qui est utilisé par ses donnés (variables, notamment pour la représentation de la page en mémoire, l'exécution du JS, les images ...)
Bref, selon la bonne vieille règle du 80 / 20, il vaut mieux s'attarder sur les 20% d'efforts qui amélioreront les perfs de 80% que l'inverse.
Ces 20% concernent à mon avis l'utilisation des bonnes structures de données (voir par exemple ce papier http://www.oopsla.org/oopsla2007/index.php?page=sub/&id=(...) ). Si tu as des entiers que tu stocke dans un int[] ou dans un map<int,int>, tu peux avoir un facteur 10 entre l'occupation mémoire de l'un ou de l'autre.
P.S. autre argument auquel j'ai oublié de répondre :
"au fur et à mesure que les deux branches vont diverger, tu n'auras plus le même rendu entre Konqueror et Plasma, les correctifs de bogues ne sont pas appliqués simultanément, ça rapidement sera le boxon."
C'est déjà le cas, webkit a été forké il y a sufisemment longtemps pour que les corrections de bugs et autre ne puissent généralement pas être appliqués à la fois à KHTML et webkit.
Quant au problème des rendus différents, il existe normalement des normes à ce sujet. Ceci dit, nous savons tous qu'elles ne sont pas appliquées parfaitement par tous les navigateurs. Et à nouveau c'est le cas, webkit et KHTML ont été forkés il y a sufisemment longtemps pour que les bugs de rendus soient différents entre les deux moteurs.
Bref, j'ai l'impression que tes arguments (hormis celui concernant la consomation mémoire qui me semble mineur) penchent plus vers l'existance d'un seul moteur que vers l'utilisation d'un seul moteur par KDE. Est-ce que tu considère aussi que Gecko devrait disparaître au profit de webkit ou est-ce que je t'ai mal compris ?
MMmouais, je pense qu'on est pas sur la même longueur d'onde et qu'on ne tombera de toute façon pas d'accord. De mon côté, il me semble vraiment qu'il s'agit d'un problème d'une importance assez faible. Il y en a bien d'autres qui méritent qu'on s'y attelle avant de mon point de vue.
Et pour "développeurs web (qui devront supporter 2 moteurs supplémentaires au lieu d'un)" c'est le cas tant que KHTML existe, même si KDE n'utilise pas webkit.
Pour le "aux utilisateurs de machines relativement peu puissante" Il faut se rendre compte qu'1Mo utilisé en RAM grand max, ça reste bon marché et que dès que tu charges quelques pages Web, ce sont ces données qui prennent de la place, pas le code lui même.
Et pour le "aux développeurs qui font les frais d'une gueguerre stupide et insidieuse." J'ai pas compris
Je ne comprend toujours pas ce que ça a de lourdingue ...
Certe, dans l'idéal, il n'y a qu'un moteur utilisé partout, pour ne pas diviser les efforts des développeurs (mais on sait que c'est un argument fallacieux) et pour limiter la consomation de mémoire (mais ce n'est vraiment pas un gros problème pour l'utilisateur vu la taille des HDs et de la RAM sur les machines actuelles) ...
Mais cet idéal n'existe nulle part. Sur toutes les machines il y a plusieurs moteurs de regexp, plusieurs parseurs XML, plusieurs bibliothèques de widgets ... Bref, des doublons.
Donc ma question reste, quel problème ça pose, et à qui ?
Sinon, concernant la kpart, c'est effectivement la solution qui semble la plus adaptée pour le long terme. Mais soyons réaliste, elle signifie certainement la mort de la kpart KHTML et de KHTML avec elle à terme. Les discussions quant à l'acceptation de ce GSOC ont donc été assez houleuses sur la ML de KDE.
Tu es con ou quoi, un suggest, c'est un paquet qui permet d'utiliser une fonctionalité supplémentaire. C'est optionnel, ce n'est pas un conseil, ce n'est pas une suggestion, ce n'est pas nécesssaire.
Il y a peut-être des distributions qui ne respectent pas la signification de suggest, mais c'est leurs oignons. En tout cas MaDistrib respecte la signification de suggest. Si un suggest ne représente pas une fonctionalité supplémentaire qui peut être ajoutée au logiciel, ben fait un rapport de bug. Tu vas voir, le suggest sera supprimé.
Il y a même une chasse quasi permanente aux suggest superflux.
[^] # Re: Et les entreprises
Posté par Julien . En réponse à la dépêche Légalisation riposte graduée / spyware : Le Monde.fr confirme. Évalué à 10.
Nos députés savent bien que si la vie privé d'un pauvre terroriste en puissancecitoyen ne vaut pas grand chose, les entreprises au contraire doivent être défendues.
Par exemple dans la loi sur la riposte graduée, la coupure de l'accès internet n'est possible que pour les personnes physiques, pas pour les entreprises (et encore moins pour l'état.)
[^] # Re: Et si rien ne disparaissait ?
Posté par Julien . En réponse à la dépêche Les GPU promis à une mort prochaine ?. Évalué à 4.
Il me semblerait logique que les deux se prêtent au parallélisme massif ... J'ai même cru entendre qu'elles arrivaient trop tard (les cartes physiques) et qu'avec les cartes graphiques programmables, leur valeur ajoutée était ridicule.
[^] # Re: Le CPU, limité dans son évolution
Posté par Julien . En réponse à la dépêche Les GPU promis à une mort prochaine ?. Évalué à 5.
Je m'explique : le OoO revient à transformer l'assembleur du binaire en un code plus finement découpé : le microcode. Ce microcode est stocké dans un "pool" dans le processeur et chaque instruction est exécutée dans le désordre (out of order) dès que ses dépendances sont satisfaites.
Une partie du processeur est donc destinée à la gestion de ce mécanisme : traduction, gestion des dépendances, etc ...
Dans le cas du bytecode, on ajoute une étape de transformation. Le bytecode est soit interprété, soit transformé en code assembleur pendant l'exécution (JIT). Il me semble que cette étape ressemble fortement à ce qui se fait pour le OoO, mais à une échelle plus large.
On pourrait donc imaginer une architecture où un coeur est destiné à la gestion de ce bytecode (exécution de la VM) et où les autres coeurs exécutent le résultat. Cette solution permettrait de tirer partie de coeurs hétérogènes : 1CPU OoO classique pour l'interprétation, un GPU pour ce qui se parallélise facilement, un VLIW pour ce qui a été JITé, un FPGA pour les tâches très répétitives, etc ...
Enfin, je divague ...
[^] # Re: Rolling Release Distros
Posté par Julien . En réponse au journal Mark Shuttleworth : il remet (encore) ça. Évalué à 3.
Alors, qu'est-ce qu'une distribution iznogoodévoluée ?
[^] # Re: Un nouveau pas !
Posté par Julien . En réponse à la dépêche Lemon : Gérez votre caisse en toute liberté !. Évalué à 8.
Dans la suite de ma réponse, je considèrerai que tu as voulu dire «La dépêche a fait l'erreur, et maintenant c'est un commentaire.» Si je me trompe, merci de l'ignorer.
J'imagine que tu dis ça en référence au troll pour savoir si avec son préprocesseur, Qt est une bibliothèque ou un langage. Ne revenons pas dessus, on sait tous qu'il n'y a pas de point de vue qui fasse consensus ici.
Considérons donc comme tu le fais que Qt est une bibliothèque, non un langage.
Je ne comprend pas en quoi cette formulation est une erreur. Certes le code est en C ou en C++ mais le résultat, l'application, est un binaire. Et l'exécution de ce binaire donne une interface en GTK ou en Qt. J'ai toujours entendu cette formulation ...
En plus de ça, dans la dépèche, il est écrit «Développé avec QT4 et les librairies mises à disposition par le projet KDE» quelle autre formulation adopter ? Il me semble que parler d'une application développée avec C ou avec C++ ne voudrait pas dire grand chose ...
Bref, je ne comprend pas la remarque. J'ai l'impression qu'à force de chercher la pureté du langage, on en vient à ne plus accepter des choses tout à fait correctes sur ce site.
C'est parce que la langue est malléable qu'on a eu de grands auteurs qui ont sû en jouer. Ce n'est pas en créant une novlang codifiée et figée qu'on se comprendra mieux.
[^] # Re: Rolling Release Distros
Posté par Julien . En réponse au journal Mark Shuttleworth : il remet (encore) ça. Évalué à 3.
Est-ce que tu pourrais m'en dire plus ?
[^] # Re: Pas à l'utilisateur de deviner
Posté par Julien . En réponse à la dépêche Gestion de l'énergie : se dépêcher de ne rien faire. Évalué à 2.
[^] # Re: Rolling Release Distros
Posté par Julien . En réponse au journal Mark Shuttleworth : il remet (encore) ça. Évalué à 3.
Elles ont juste des buts et des points forts différents.
[^] # Re: Rolling Release Distros
Posté par Julien . En réponse au journal Mark Shuttleworth : il remet (encore) ça. Évalué à -1.
Entendre Fedora
[^] # Re: Voici pourquoi openssl lit de la mémoire non initialisée (et ce n'
Posté par Julien . En réponse à la dépêche Découverte d'une faille de sécurité critique dans OpenSSL de Debian. Évalué à 1.
[^] # Re: Voici pourquoi openssl lit de la mémoire non initialisée (et ce n'
Posté par Julien . En réponse à la dépêche Découverte d'une faille de sécurité critique dans OpenSSL de Debian. Évalué à 3.
> M'enfin, c'est limite un coup de chance.
Je crois que ces deux lignes suffisent à appréhender la suffisance du personnage.
Surtout après avoir passé une page de commentaires à détruire le mainteneur debian, parce qu'il a fait une erreur et c'est impardonnable et ça arriverait pas chez ...
[^] # Re: Tous ces commentaires sont désolants ...
Posté par Julien . En réponse à la dépêche Découverte d'une faille de sécurité critique dans OpenSSL de Debian. Évalué à 2.
Eheh, non, il me semble au contraire qu'il est aussi difficile de se faire virer de la SG que de debian ;)
Pour la petite histoire, je crois qu'il était spécifié dans le contrat de Jérôme K. qu'un renvoi doit être précédé par un entretient avec sa hiérarchie ... Oui, sauf qu'il a justement l'interdiction légale d'avoir des contacts avec sa hiérarchie ou toute autre personne liée à l'affaire pendant l'enquête.
[^] # Re: justement, quel impact sur Solid de KDE4 ?
Posté par Julien . En réponse à la dépêche Nouveautés et perspectives pour HAL. Évalué à 6.
[^] # Re: Je craque
Posté par Julien . En réponse à la dépêche Qt 4.4 prend son envol. Évalué à -1.
[^] # Re: Le retour du Troll (WebKit Vs KHTML)
Posté par Julien . En réponse à la dépêche Qt 4.4 prend son envol. Évalué à 5.
Le vrai argument ici, c'est que dans ce cas, l'espace utilisé par le code est négligeable par rapport à celui utilisé par les donnés.
Je n'ai pas de chiffre sous les yeux, mais je ne serais pas étonné que l'espace utilisé par le code de KHTML en mémoire soit inférieur d'au moins un ordre de grandeur à ce qui est utilisé par ses donnés (variables, notamment pour la représentation de la page en mémoire, l'exécution du JS, les images ...)
Bref, selon la bonne vieille règle du 80 / 20, il vaut mieux s'attarder sur les 20% d'efforts qui amélioreront les perfs de 80% que l'inverse.
Ces 20% concernent à mon avis l'utilisation des bonnes structures de données (voir par exemple ce papier http://www.oopsla.org/oopsla2007/index.php?page=sub/&id=(...) ). Si tu as des entiers que tu stocke dans un int[] ou dans un map<int,int>, tu peux avoir un facteur 10 entre l'occupation mémoire de l'un ou de l'autre.
[^] # Re: Le retour du Troll (WebKit Vs KHTML)
Posté par Julien . En réponse à la dépêche Qt 4.4 prend son envol. Évalué à 2.
"au fur et à mesure que les deux branches vont diverger, tu n'auras plus le même rendu entre Konqueror et Plasma, les correctifs de bogues ne sont pas appliqués simultanément, ça rapidement sera le boxon."
C'est déjà le cas, webkit a été forké il y a sufisemment longtemps pour que les corrections de bugs et autre ne puissent généralement pas être appliqués à la fois à KHTML et webkit.
Quant au problème des rendus différents, il existe normalement des normes à ce sujet. Ceci dit, nous savons tous qu'elles ne sont pas appliquées parfaitement par tous les navigateurs. Et à nouveau c'est le cas, webkit et KHTML ont été forkés il y a sufisemment longtemps pour que les bugs de rendus soient différents entre les deux moteurs.
Bref, j'ai l'impression que tes arguments (hormis celui concernant la consomation mémoire qui me semble mineur) penchent plus vers l'existance d'un seul moteur que vers l'utilisation d'un seul moteur par KDE. Est-ce que tu considère aussi que Gecko devrait disparaître au profit de webkit ou est-ce que je t'ai mal compris ?
[^] # Re: Le retour du Troll (WebKit Vs KHTML)
Posté par Julien . En réponse à la dépêche Qt 4.4 prend son envol. Évalué à 1.
Et pour "développeurs web (qui devront supporter 2 moteurs supplémentaires au lieu d'un)" c'est le cas tant que KHTML existe, même si KDE n'utilise pas webkit.
Pour le "aux utilisateurs de machines relativement peu puissante" Il faut se rendre compte qu'1Mo utilisé en RAM grand max, ça reste bon marché et que dès que tu charges quelques pages Web, ce sont ces données qui prennent de la place, pas le code lui même.
Et pour le "aux développeurs qui font les frais d'une gueguerre stupide et insidieuse." J'ai pas compris
[^] # Re: Le retour du Troll (WebKit Vs KHTML)
Posté par Julien . En réponse à la dépêche Qt 4.4 prend son envol. Évalué à 2.
Certe, dans l'idéal, il n'y a qu'un moteur utilisé partout, pour ne pas diviser les efforts des développeurs (mais on sait que c'est un argument fallacieux) et pour limiter la consomation de mémoire (mais ce n'est vraiment pas un gros problème pour l'utilisateur vu la taille des HDs et de la RAM sur les machines actuelles) ...
Mais cet idéal n'existe nulle part. Sur toutes les machines il y a plusieurs moteurs de regexp, plusieurs parseurs XML, plusieurs bibliothèques de widgets ... Bref, des doublons.
Donc ma question reste, quel problème ça pose, et à qui ?
[^] # Re: Le retour du Troll (WebKit Vs KHTML)
Posté par Julien . En réponse à la dépêche Qt 4.4 prend son envol. Évalué à 2.
Si je dis "chez moi, Emacs est inutilisable alors que vim marche nikel" ça peut être vrai, ça n'en est pas moins un lancer de troll.
[^] # Re: Tout en un ?
Posté par Julien . En réponse à la dépêche Qt 4.4 prend son envol. Évalué à 6.
[^] # Re: Le retour du Troll (WebKit Vs KHTML)
Posté par Julien . En réponse à la dépêche Qt 4.4 prend son envol. Évalué à 1.
Sinon, concernant la kpart, c'est effectivement la solution qui semble la plus adaptée pour le long terme. Mais soyons réaliste, elle signifie certainement la mort de la kpart KHTML et de KHTML avec elle à terme. Les discussions quant à l'acceptation de ce GSOC ont donc été assez houleuses sur la ML de KDE.
Sinon, j'avais déjà écrit ici https://linuxfr.org/2008/04/02/23928.html#919463 un commentaire concernant ce qui me semble être les arguments des uns et des autres à ce sujet.
[^] # Re: Le retour du Troll (WebKit Vs KHTML)
Posté par Julien . En réponse à la dépêche Qt 4.4 prend son envol. Évalué à 1.
[^] # Re: Le retour du Troll (WebKit Vs KHTML)
Posté par Julien . En réponse à la dépêche Qt 4.4 prend son envol. Évalué à 2.
Sinon, un GSOC pour la solution 2 est en cours (kpart webkit)
[^] # Re: dommage
Posté par Julien . En réponse à la dépêche Sortie de la Mandriva Linux 2008.1 Spring. Évalué à 3.
Il y a peut-être des distributions qui ne respectent pas la signification de suggest, mais c'est leurs oignons. En tout cas MaDistrib respecte la signification de suggest. Si un suggest ne représente pas une fonctionalité supplémentaire qui peut être ajoutée au logiciel, ben fait un rapport de bug. Tu vas voir, le suggest sera supprimé.
Il y a même une chasse quasi permanente aux suggest superflux.
[^] # Re: dommage
Posté par Julien . En réponse à la dépêche Sortie de la Mandriva Linux 2008.1 Spring. Évalué à 2.
La réponse courte : oui aptitude le permet
La réponse moyenne :
aptitude search '?not(?installed)?reverse-suggests(?installed)'
ou
aptitude search '!~i~R[suggest]~i'
La réponse plus longue :
http://algebraicthunk.net/~dburrows/projects/aptitude/doc/fr(...)