Il y a maintenant quelques années, il y avait un comparatif en une gentoo et une debian, la debian étant alors compilé pour du 486 (maintenant, c'est du 586 il me semble). Grosso modo, la debian allait plus vite en moyenne...
Sur debian, seuls quelques paquets sont optimisés pour l'architecture, pour 90% des logiciels, cela ne change rien (et je suis gentils sur le 90%).
Je crois que mplayer détecte maintenant tout seul le type de processeur et optimise de lui même le code à charger... Il n'y a même plus besoin d'avoir plusieurs versions.
Bref, comme dans un code de calcul, on connait plus ou moins les goulots d'étranglement sur un poste de travail. Cabler l'AES dans le microprocesseur plus ajouter du traitement du signal vidéo pour le H264 vont à mon avis éliminer une bonne partie des ralentissements du poste de madame michu.
Lorsque tu fait des grosses modifs comme cela, tu ne les mets pas obligatoire au début puis tu les rends pas défaut lorsqu'il y a du recul dessus.
Si tu commences à péter des gros projets parce que les options pas défaut ont trop changé, tu fait fuir les gens de ton projet. Si tu obliges les gens à modifier leur chaine de compilation car le compilateur merde car optimise trop, tu es mal. J'ai vu des codes de calcul qui donnent des résultats faux selon les paramêtres d'optimisation. Trop vouloir optimiser ne donnent pas toujours un résultat juste.
Je penses que tu n'as aucune conscience de la responsabilité et du stress que prennent les développeur de GCC a chaque version...
Sauf que tes propos sont légèrement péjoratif envers GNU et debian et non simplement explicatif, par exemple ton bout de phrase : <<sauf la FSF et les autres gnuistes integristes>>.
On partage ou ne partage pas la philosophie derrière GNU. Debian est effecivement une distribution qui, de ce point de vu, a toujours eu une forte personnalité et qui n'intègre dans la branche main que des choses qu'elle considère comme 'libre' selon sa propre définition.
Dis autrement, Debian a beaucoup participé à la notion même << de logiciel libre >>.
Non pas vraiment. C'est une debian donc c'est un noyau FreeBSD dans l'environnement debian basé sur GNU. Donc, ce sera normalement les mêmes paquets que sur les autres debian sauf quelques paquets spécifique pour cette architecture (pf à la place d'iptables)... Il ne s'agit donc pas de reprendre les ports FreeBSD pour relooker à la sauce apt-get, mais bien de compiler l'ensemble des paquets déjà existant dans debian sur le noyau FreeBSD. Evidement, les patch spécifique réalisé par les équipes des BSD pour que cela marche chez eux seront repris.
On peut dire que c'est une autre version de BSD mais pas complètement car la philosophie des versions debian est de s'intégrer dans l'environnement debian et il n'y a donc d'objectif de ré-écrire sous licence BSD des programmmes qui marchent déjà très bien sous licence GPL. C'est juste un exemple.
Bref, l'environnement debian va être une formidable architecture de test pour les projets logiciels car on a sous la main pas mal d'architecture matérielle et plusieurs OS sous la main. Lorsqu'un logiciel marchera sous tout cela, on peut être sur qu'un sacré paquet de bogues auront déjà été trouvé.
C'est pour bien dire que c'est le noyau de FreeBSD et non tout FreeBSD. Le premier coup, cela m'a surpris mais je pense que c'est ce qu'il y avait de meiux à faire. Sinon, on aurait cru avoir les mêmes ports que FreeBSD mais sous forme apt-get alors qu'en pratique, ce n'est pas du tout cela.
En effet, ce portage du noyau FreeBSD utilise au maximum les paquetages déjà existant chez Debian, d'ou le GNU. Evidement, il y aura des paquetages spécial pour cette architecture comme pf à la place d'iptables... Normalement, le nombre de paquetage différent va être réduit au minimum.
Au final, cette Debian a noyau FreeBSD ne devrait pas ressembler tant que cela à FreeBSD. Il y a des chances que les autres BSD ressemble plus à FreeBSD. L'environnement de la debian sera le même que sur les autres debian et sera donc complètement basé sur les composants GNU.
Sauf que le bind dans le chroot n'est pas mis a jour aussi facilement que les binaires de la distribution... Bref, j'ai vu des bind en chroot qui n'étaient clairement plus mis à jour.
Si chroot, bien penser à la procédure de mise à jour de tout ce qui est dans le chroot.
Je ne suis pas spécialiste des BSD mais par exemple avec Debian, on peut avoir le paquet machin avec à coté machin-dbg, machin-doc, machin-dev, libmachin et libmachin-dev. Selon la manière dont est saucissonné un paquet, on arrive à des chiffres assez différent.
Le nombre de paquetage d'une distribution est donc juste une indication mais il ne faut pas toujours prendre cette valeur pour une référence absolue.
Ceci dis, je ne suis pas surpris que NetBSD est moins de paquetage que FreeBSD.
A terme, on aura un système BSD qui se gère comme une debian avec le même installateur... On pourra avoir une machine virtuelle BSD comme on a des LINUX.
C'est tout simplement génial d'avoir plusieurs noyaux pour un même environnement. Je ne suis pas du tout sur que cela reste anecdotique. Il est possible que cette version BSD prenne une place importante dans le paysage.
Il faut voir le nombre d'outil qui gravite autour de debian et qui vont à terme marcher pareil sur ce noyau.
Bon, étant enthousiasmé, j'avoue ne pas être objectif.
> Ah, et quelle implémentation robuste y a-t-il à l'heure actuelle ?
Aucune puisque justement, la version 1 indique qu'a partir de maintenant, on peut essayer de faire du robuste !
Quand a PyPy, si tu penses réellement que ce que tu annonces pour lui le rend plus ambitieux que de concevoir une machine virtuelle à pile qui soit générique pour tous les langages de script, libre à toi. Il ne faut pas cependant que le Python te voile l'objectivité.
Parrot a été imaginé pour faire tourner tant Perl que Python, que Tcl...
C'est la première machine virtuelle conçu collaborativement et spécifiquement pour les langages de script. Alors non, je n'accepte pas ton déni : "Yet Another Virtual Machine". C'est vraiment du n'importe quoi.
Si vous arrêtiez de déformer mes propos et si vous lisiez un peu mieux ce que j'écris, vous verriez que
-1- je n'agresse pas les gens
-2- je n'ai jamais dis que l'américain est une langue séparée de l'anglais
Donc reprenons. Au québec, les personnes ne parlent pas le francais de la métropole. Tu peux appeller cela le québecois ou le français du québec ou ce que tu veux. Donc je dis qu'ils ne parlent pas le francais de la métropole qui est le francais majoritaire. Donc le québecois est une variante du francais de métropole que pour simplifier et parce que nous sommes en métropole, nous appelons par simplification 'francais' tout court.
C'est pareil pour l'américain qui est une variante de l'anglais. Sauf que l'américain est majoritaire et que c'est ce que nous parlons globalement dans les échanges internationnaux. Les commentaires des codes sont principalement en américain, variante de l'anglais car celui-ci est le mieux parlé de par le monde.
Après, que vous ayez tous des noeuds parce que je dis que les commentaires sont en américain et pas en anglais, c'est votre problème. Cela commence à faire pas mal de fois que j'explique ma position dans ce post et que vous détournez le sujet pour essayer de monter les gens les uns contre les autres. Cela ne m'interesse pas.
Aujourd'hui, c'est l'américain, variante de l'anglais, qui est majoritairement parlé que vous le vouliez ou non. Les commentaires de mes codes, je l'ai fait en américain et non en anglais car pour moi, l'anglais tout court, c'est l'anglais de la grande bretagne et je ne le maîtrise pas.
Alors si tu veux, tu fait tes commentaires en anglais variante nord-américaine... Moi, je préfère appeller un chat un chat et dire que je les fait en américain directement. En pratique, nous faisons la même chose.
Je n'ai pas parlé de politique dans mon post et je n'ai aucun problème pour en parler sur linuxfr lorsque je le désire. Donc s'il te plait, n'insinue pas des choses et prends en la responsabilité si tu souhaites mettre le débat sur ce sujet là.
Moi, je dis juste que la majorité des gens pensent parler anglais alors qu'ils parlent américain. C'est tout. Si tu penses que dire cela, c'est faire de la politique, nous n'avons pas la même vision de la politique. Je fais juste une constatation.
Après on peut faire de la linguistique et parlé de frontière... Tu as toujours des cas particuliers qui sont à cheval.
Enfin, nous sommes d'accord sur un point : "Donc la variante commune est l'anglais nord-américain, qui a le bon goût d'être compris par la majorité des anglophones". En effet, c'est actuellement le dialecte international qui est parlé sur le continent nord américain. Heureusement que les anglais de souche comprennent ce dialecte (puisque même une grande partie des francais aussi ;-) ).
J'ai déjà fait des sites web en anglais et en 'anglais nord américain', il y a pas mal de mot qui change au niveau des menus... et dans le texte. Si tu es capable de basculer de l'un vers l'autre, tant mieux pour toi. Moi personnellement, je n'y arrive pas et je pense que nous sommes une grande majorité dans ce cas.
La question ne se pose pas. Lorsque le Français était la langue internationale, c'était le Français de métropole.
Par ailleurs, dans la cadre du francais, le francais de métropole est majoritaire. Le québécois, le belge... sont donc des variantes.
En ce qui concerne la langue que nous utilisons pour dialoguer à l'intertationale, c'est un charabia qui a plus une base proche de l'américain que de l'anglais. L'américain est un dérivée de l'anglais mais il est devenu majoritaire de nos jours.
Quand un anglais entend notre chariabia, il saute en l'air.
Bref, pour ces bonnes et mauvaises raisons, il est à mon sens préférable de dire que l'américain est la langue dominante et non l'anglais. Si le québécois le devient un jour, cela ne me dérange pas qu'on dise le québecois plutôt que le français. Mais bon, je pense que la future langue internationnale sera l'espagnol... Cela pourrait être le chinois mais c'est trop compliqué pour vraiment se généraliser et même en chine, il y a plusieurs chinois...
Remettons les choses au clair. Ce n'est pas l'anglais la langue internationale en ce moment mais l'américains qui est un dérivée de l'anglais.
Plein de mots sont différents entre l'anglais et l'américains. Je sais pour avoir eu des anglais à coté de moi que je parle plutôt l'américains (comme un pied) que l'anglais et que cela est valable pour une très grande partie des chercheurs que je cotois. Je ne vois pas pourquoi cela serait différent dans le monde de l'entreprise.
Donc on répète tous ensenmble : << La langue dominante de nos jours est l'américains >>.
> Parrot est significativement plus rapide que Python
Ben c'est déjà pas mal pour un projet communautaire dans sa version 1 dont l'objectif premier n'est pas la production mais d'avoir des implémentations robustes de langage de script qui tourne dessus.
En parallèle, évidement que la machine Parrot va être encore optimisé.
Sinon, je ne vois pas en quoi PyPy est autrement plus ambitieux ? Je suis désolé mais Parrot a une dimension universelle que je ne vois pas du tout dans PyPy. Les deux projets me paraissent sans commune mesure.
Avant, j'allais voir du coté de Perl6 mais il ne m'a fallu plus de 10 mn pour déjà trouver tout cela.
Les mailings lists et les planets de Perl6 et de Parrot étaient bien entrelacé jusqu'a la version 1 de Parrot. C'est un peu logique car les deux se sont mutuellement aidés pour améliorer leur design (et puis ce sont quasiment les mêmes personnes).
Avec Parrot 1.0, Perl 6 est dans sa ligne droite finale pour sortir en fin d'année une remière version utilisable.
Les planets et les mailling list vont se séparer naturellement.
Encore une fois, les personnes de Google savent parfaitement cela. Il n'est pas imaginable que personne chez Google n'ait suivis de près la co-conception par la communauté de Parrot et de Perl. C'est un évènement suffisament rarissime pour avoir un oeil qui suit cela.
Cela n'a rien a voir. Derrière Java il y avait tout le marketing SUN qui voulait nous faire croire qu'il avait tout inventé et que c'était trivial.
Derrière Parrot, il y a une communauté, surtout porté par Perl au début mais dont l'objectif est d'être de plus en plus autonome. D'ailleurs, les sites Web de parrot et de Perl6 sont maintenant distinct.
Encore une fois, il ne s'agit pas d'un petit projet porté par une petite boite mais de Google ! Ce n'est pas un projet avec un objectif à six mois d'après ce que j'ai compris.
Personne n'a dis d'utiliser la version 1 de Parrot pour faire de la production. Non, la version 1 est faite pour que les langages de scripts essayent de faire une implémentation sur Parrot afin de voir en grandeur nature ce que donne Parrot.
Il est assez facile d'avoir des info sur Parrot même si le site web n'est pas son fort. Parrot vient de sortir en version 1.0 Pour une entreprise comme Google et ayant forcément des informaticiens bon (très bon) en Perl, ils ne peuvent pas ne pas être au courant de l'état de Parrot.
En plus, Parrot est au GSoC.
Bref, ma remarque est à lire dans le contexte de Google et non d'une boite lambda.
Altix 4700 : machine SMP pouvant avoir 2048 coeurs ! (1024 sur le catalogue)
Machine ICE cluster Xeon, celle du CINES a 12000 coeurs.
Cluster graphique
....
Bref, SGI a de très belle machine a son catalogue. Ils sont spécialisé sur le calcul et rien que le calcul. Ils sont donc sur un marché de niche et si tu n'est pas sur ce domaine, tu ne les vois plus.
Je peux te dire qu'autour de moi, il y a BEAUCOUP de machine SGI, mais ces machines n'ont rien à voir avec les machines que nous pouvions avoir il y a 10 ans. Il ne faut pas s'attendre à voir une SGI dans un bureau de nos jours. SGI ne fait que des machines qui se place dans les salles serveurs.
C'est dommage qu'il ne travaille pas au portage de Python sur Parrot. Parrot, cest LA MACHINE VIRTUELLE conçu pour les langages de script et conçu de manière communautaire et libre (même si c'est, pour des raisons historiques, globalement piloté par les gens de Perl).
Avoir la force de frappe de Google sur Parrot aurait été un gros plus pour ce projet.
Je viens de lire en diagonale et c'est vachement intéressant. Cela donne un autre point de vu. Par exemple, je pensais qu'OpenERP était le leader alors que cela semble compiere.
Bref, à lire pour avoir un point de vue différent de ce que je vois autour de moi dans nos laboratoires de recherche.
[^] # Re: Gains de performance
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de la version 4.4 du compilateur GCC. Évalué à 8.
Sur debian, seuls quelques paquets sont optimisés pour l'architecture, pour 90% des logiciels, cela ne change rien (et je suis gentils sur le 90%).
Je crois que mplayer détecte maintenant tout seul le type de processeur et optimise de lui même le code à charger... Il n'y a même plus besoin d'avoir plusieurs versions.
Bref, comme dans un code de calcul, on connait plus ou moins les goulots d'étranglement sur un poste de travail. Cabler l'AES dans le microprocesseur plus ajouter du traitement du signal vidéo pour le H264 vont à mon avis éliminer une bonne partie des ralentissements du poste de madame michu.
# Jamais content
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de la version 4.4 du compilateur GCC. Évalué à 9.
Si tu commences à péter des gros projets parce que les options pas défaut ont trop changé, tu fait fuir les gens de ton projet. Si tu obliges les gens à modifier leur chaine de compilation car le compilateur merde car optimise trop, tu es mal. J'ai vu des codes de calcul qui donnent des résultats faux selon les paramêtres d'optimisation. Trop vouloir optimiser ne donnent pas toujours un résultat juste.
Je penses que tu n'as aucune conscience de la responsabilité et du stress que prennent les développeur de GCC a chaque version...
[^] # Re: Le quatrième plus gros contributeur au noyau Linux?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Oracle achète Sun. Évalué à 6.
[^] # Re: Falcon ou InnoDB ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Oracle achète Sun. Évalué à 10.
Abandonner Linux est à mon avis sucidaire pour eux.
Pour Btrfs, j'ai pas d'avis tranché... C'est vrai que passer le code de ZFS en GPL (ou BSD) pourrait être plus simple...
[^] # Re: Cooool, on vient d'inventer un nouveau troll totalement inutile.
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Night of the living BSDeads. Évalué à 3.
On partage ou ne partage pas la philosophie derrière GNU. Debian est effecivement une distribution qui, de ce point de vu, a toujours eu une forte personnalité et qui n'intègre dans la branche main que des choses qu'elle considère comme 'libre' selon sa propre définition.
Dis autrement, Debian a beaucoup participé à la notion même << de logiciel libre >>.
[^] # Re: C'est d'autant plus vrai que ...
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Night of the living BSDeads. Évalué à 7.
Non pas vraiment. C'est une debian donc c'est un noyau FreeBSD dans l'environnement debian basé sur GNU. Donc, ce sera normalement les mêmes paquets que sur les autres debian sauf quelques paquets spécifique pour cette architecture (pf à la place d'iptables)... Il ne s'agit donc pas de reprendre les ports FreeBSD pour relooker à la sauce apt-get, mais bien de compiler l'ensemble des paquets déjà existant dans debian sur le noyau FreeBSD. Evidement, les patch spécifique réalisé par les équipes des BSD pour que cela marche chez eux seront repris.
On peut dire que c'est une autre version de BSD mais pas complètement car la philosophie des versions debian est de s'intégrer dans l'environnement debian et il n'y a donc d'objectif de ré-écrire sous licence BSD des programmmes qui marchent déjà très bien sous licence GPL. C'est juste un exemple.
Bref, l'environnement debian va être une formidable architecture de test pour les projets logiciels car on a sous la main pas mal d'architecture matérielle et plusieurs OS sous la main. Lorsqu'un logiciel marchera sous tout cela, on peut être sur qu'un sacré paquet de bogues auront déjà été trouvé.
[^] # Re: Architecture vs paquet
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Deux cœurs BSD chez Debian. Évalué à 2.
En effet, ce portage du noyau FreeBSD utilise au maximum les paquetages déjà existant chez Debian, d'ou le GNU. Evidement, il y aura des paquetages spécial pour cette architecture comme pf à la place d'iptables... Normalement, le nombre de paquetage différent va être réduit au minimum.
Au final, cette Debian a noyau FreeBSD ne devrait pas ressembler tant que cela à FreeBSD. Il y a des chances que les autres BSD ressemble plus à FreeBSD. L'environnement de la debian sera le même que sur les autres debian et sera donc complètement basé sur les composants GNU.
[^] # Re: Parce que
Posté par Sytoka Modon (site web personnel) . En réponse au message Pourquoi chrooter bind ?. Évalué à 6.
Si chroot, bien penser à la procédure de mise à jour de tout ce qui est dans le chroot.
[^] # Re: Intérêt ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Deux cœurs BSD chez Debian. Évalué à 3.
Le nombre de paquetage d'une distribution est donc juste une indication mais il ne faut pas toujours prendre cette valeur pour une référence absolue.
Ceci dis, je ne suis pas surpris que NetBSD est moins de paquetage que FreeBSD.
[^] # Re: Intérêt ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Deux cœurs BSD chez Debian. Évalué à 8.
C'est tout simplement génial d'avoir plusieurs noyaux pour un même environnement. Je ne suis pas du tout sur que cela reste anecdotique. Il est possible que cette version BSD prenne une place importante dans le paysage.
Il faut voir le nombre d'outil qui gravite autour de debian et qui vont à terme marcher pareil sur ce noyau.
Bon, étant enthousiasmé, j'avoue ne pas être objectif.
[^] # Re: Parrot
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Le projet Unladen Swallow vise à accélérer Python d'un facteur 5. Évalué à 1.
Aucune puisque justement, la version 1 indique qu'a partir de maintenant, on peut essayer de faire du robuste !
Quand a PyPy, si tu penses réellement que ce que tu annonces pour lui le rend plus ambitieux que de concevoir une machine virtuelle à pile qui soit générique pour tous les langages de script, libre à toi. Il ne faut pas cependant que le Python te voile l'objectivité.
Parrot a été imaginé pour faire tourner tant Perl que Python, que Tcl...
C'est la première machine virtuelle conçu collaborativement et spécifiquement pour les langages de script. Alors non, je n'accepte pas ton déni : "Yet Another Virtual Machine". C'est vraiment du n'importe quoi.
[^] # Re: Dommage
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Logram, environnement de bureau totalement différent, fête ses 1 ans.. Évalué à 0.
-1- je n'agresse pas les gens
-2- je n'ai jamais dis que l'américain est une langue séparée de l'anglais
Donc reprenons. Au québec, les personnes ne parlent pas le francais de la métropole. Tu peux appeller cela le québecois ou le français du québec ou ce que tu veux. Donc je dis qu'ils ne parlent pas le francais de la métropole qui est le francais majoritaire. Donc le québecois est une variante du francais de métropole que pour simplifier et parce que nous sommes en métropole, nous appelons par simplification 'francais' tout court.
C'est pareil pour l'américain qui est une variante de l'anglais. Sauf que l'américain est majoritaire et que c'est ce que nous parlons globalement dans les échanges internationnaux. Les commentaires des codes sont principalement en américain, variante de l'anglais car celui-ci est le mieux parlé de par le monde.
Après, que vous ayez tous des noeuds parce que je dis que les commentaires sont en américain et pas en anglais, c'est votre problème. Cela commence à faire pas mal de fois que j'explique ma position dans ce post et que vous détournez le sujet pour essayer de monter les gens les uns contre les autres. Cela ne m'interesse pas.
Aujourd'hui, c'est l'américain, variante de l'anglais, qui est majoritairement parlé que vous le vouliez ou non. Les commentaires de mes codes, je l'ai fait en américain et non en anglais car pour moi, l'anglais tout court, c'est l'anglais de la grande bretagne et je ne le maîtrise pas.
Alors si tu veux, tu fait tes commentaires en anglais variante nord-américaine... Moi, je préfère appeller un chat un chat et dire que je les fait en américain directement. En pratique, nous faisons la même chose.
[^] # Re: Dommage
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Logram, environnement de bureau totalement différent, fête ses 1 ans.. Évalué à -1.
Moi, je dis juste que la majorité des gens pensent parler anglais alors qu'ils parlent américain. C'est tout. Si tu penses que dire cela, c'est faire de la politique, nous n'avons pas la même vision de la politique. Je fais juste une constatation.
Après on peut faire de la linguistique et parlé de frontière... Tu as toujours des cas particuliers qui sont à cheval.
Enfin, nous sommes d'accord sur un point : "Donc la variante commune est l'anglais nord-américain, qui a le bon goût d'être compris par la majorité des anglophones". En effet, c'est actuellement le dialecte international qui est parlé sur le continent nord américain. Heureusement que les anglais de souche comprennent ce dialecte (puisque même une grande partie des francais aussi ;-) ).
J'ai déjà fait des sites web en anglais et en 'anglais nord américain', il y a pas mal de mot qui change au niveau des menus... et dans le texte. Si tu es capable de basculer de l'un vers l'autre, tant mieux pour toi. Moi personnellement, je n'y arrive pas et je pense que nous sommes une grande majorité dans ce cas.
[^] # Re: Dommage
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Logram, environnement de bureau totalement différent, fête ses 1 ans.. Évalué à 1.
Par ailleurs, dans la cadre du francais, le francais de métropole est majoritaire. Le québécois, le belge... sont donc des variantes.
En ce qui concerne la langue que nous utilisons pour dialoguer à l'intertationale, c'est un charabia qui a plus une base proche de l'américain que de l'anglais. L'américain est un dérivée de l'anglais mais il est devenu majoritaire de nos jours.
Quand un anglais entend notre chariabia, il saute en l'air.
Bref, pour ces bonnes et mauvaises raisons, il est à mon sens préférable de dire que l'américain est la langue dominante et non l'anglais. Si le québécois le devient un jour, cela ne me dérange pas qu'on dise le québecois plutôt que le français. Mais bon, je pense que la future langue internationnale sera l'espagnol... Cela pourrait être le chinois mais c'est trop compliqué pour vraiment se généraliser et même en chine, il y a plusieurs chinois...
[^] # Re: Dommage
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Logram, environnement de bureau totalement différent, fête ses 1 ans.. Évalué à -3.
Plein de mots sont différents entre l'anglais et l'américains. Je sais pour avoir eu des anglais à coté de moi que je parle plutôt l'américains (comme un pied) que l'anglais et que cela est valable pour une très grande partie des chercheurs que je cotois. Je ne vois pas pourquoi cela serait différent dans le monde de l'entreprise.
Donc on répète tous ensenmble : << La langue dominante de nos jours est l'américains >>.
[^] # Re: Parrot
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Le projet Unladen Swallow vise à accélérer Python d'un facteur 5. Évalué à 2.
Ben c'est déjà pas mal pour un projet communautaire dans sa version 1 dont l'objectif premier n'est pas la production mais d'avoir des implémentations robustes de langage de script qui tourne dessus.
En parallèle, évidement que la machine Parrot va être encore optimisé.
Sinon, je ne vois pas en quoi PyPy est autrement plus ambitieux ? Je suis désolé mais Parrot a une dimension universelle que je ne vois pas du tout dans PyPy. Les deux projets me paraissent sans commune mesure.
[^] # Re: Parrot
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Le projet Unladen Swallow vise à accélérer Python d'un facteur 5. Évalué à 3.
http://www.parrot.org
Les objectifs de la version 1_0
http://www.parrot.org/news/vision-for-1_0
La doc de Parrot
http://docs.parrot.org/parrot/latest/html/
Le trac de Parrot
https://trac.parrot.org
Les bug
https://trac.parrot.org/parrot/report
Pour soumettre un bogue
http://docs.parrot.org/parrot/latest/html/docs/submissions.p(...)
Les langages utilisant Parrot
http://www.parrot.org/languages
Le 'planet' de Parrot
http://planet.parrotcode.org/
...
Avant, j'allais voir du coté de Perl6 mais il ne m'a fallu plus de 10 mn pour déjà trouver tout cela.
Les mailings lists et les planets de Perl6 et de Parrot étaient bien entrelacé jusqu'a la version 1 de Parrot. C'est un peu logique car les deux se sont mutuellement aidés pour améliorer leur design (et puis ce sont quasiment les mêmes personnes).
Avec Parrot 1.0, Perl 6 est dans sa ligne droite finale pour sortir en fin d'année une remière version utilisable.
Les planets et les mailling list vont se séparer naturellement.
Encore une fois, les personnes de Google savent parfaitement cela. Il n'est pas imaginable que personne chez Google n'ait suivis de près la co-conception par la communauté de Parrot et de Perl. C'est un évènement suffisament rarissime pour avoir un oeil qui suit cela.
[^] # Re: Parrot
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Le projet Unladen Swallow vise à accélérer Python d'un facteur 5. Évalué à 2.
Derrière Parrot, il y a une communauté, surtout porté par Perl au début mais dont l'objectif est d'être de plus en plus autonome. D'ailleurs, les sites Web de parrot et de Perl6 sont maintenant distinct.
Encore une fois, il ne s'agit pas d'un petit projet porté par une petite boite mais de Google ! Ce n'est pas un projet avec un objectif à six mois d'après ce que j'ai compris.
Personne n'a dis d'utiliser la version 1 de Parrot pour faire de la production. Non, la version 1 est faite pour que les langages de scripts essayent de faire une implémentation sur Parrot afin de voir en grandeur nature ce que donne Parrot.
[^] # Re: BIOS
Posté par Sytoka Modon (site web personnel) . En réponse au journal Mort au bip. Évalué à 2.
[^] # Re: BIOS
Posté par Sytoka Modon (site web personnel) . En réponse au journal Mort au bip. Évalué à 2.
Bref, EFI, j'ai une machine Itanium avec et je ne trouve pas que ce soit mieux que le BIOS.
[^] # Re: Parrot
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Le projet Unladen Swallow vise à accélérer Python d'un facteur 5. Évalué à 2.
En plus, Parrot est au GSoC.
Bref, ma remarque est à lire dans le contexte de Google et non d'une boite lambda.
[^] # Re: Une conséquence des machines virtuelles
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Le projet Unladen Swallow vise à accélérer Python d'un facteur 5. Évalué à 2.
[^] # Re: FREMONT, CA and SUNNYVALE, CA., April 1, 2009
Posté par Sytoka Modon (site web personnel) . En réponse au journal Silicon Graphics, Inc. racheté par Rackable Systems, Inc.. Évalué à 8.
Machine ICE cluster Xeon, celle du CINES a 12000 coeurs.
Cluster graphique
....
Bref, SGI a de très belle machine a son catalogue. Ils sont spécialisé sur le calcul et rien que le calcul. Ils sont donc sur un marché de niche et si tu n'est pas sur ce domaine, tu ne les vois plus.
Je peux te dire qu'autour de moi, il y a BEAUCOUP de machine SGI, mais ces machines n'ont rien à voir avec les machines que nous pouvions avoir il y a 10 ans. Il ne faut pas s'attendre à voir une SGI dans un bureau de nos jours. SGI ne fait que des machines qui se place dans les salles serveurs.
# Parrot
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Le projet Unladen Swallow vise à accélérer Python d'un facteur 5. Évalué à 1.
Avoir la force de frappe de Google sur Parrot aurait été un gros plus pour ce projet.
# C'est vachement bien
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche La 4ème édition de l'observatoire du libre vient de sortir !. Évalué à 4.
Bref, à lire pour avoir un point de vue différent de ce que je vois autour de moi dans nos laboratoires de recherche.