À noter que MS Office pour Android n'existe pas, et qu'OpenOffice non plus (peut être est-il trop lourd pour fonctionner sur les SmartPhone ou Netbook ?)
Ce n'est pas qu'une question de poids. Vu la puissance des derniers appareils sortis...
Premier point, OpenOffice.org n'est pas conçu pour une interface de type smartphone ou un écran trop petit (pour un netbook, c'est donc limite)
Deuxième point, Android est trop différent d'une plateforme Linux traditionnelle pour qu'une simple recompilation suffise pour y porter OpenOffice.org : il faudrait installer un serveur X, revoir aussi pas mal d'éléments de l'interface graphique... Porter proprement OpenOffice.org sur Android sera(it) un travail titanesque (en jouant avec le NDK, et en réécrivant pas mal de morceaux d'OpenOffice.org, ça doit être faisable), je ne pense pas que beaucoup de volontaires se présentent pour le réaliser...
Le soucis, c'est que (en tout cas dans mon cas) en cours, on apprend aux pauvres petits étudiants les EJB, struts et autres horreurs...
Forcément après quand ils voient <?php echo "hello world"; ?> ils sont excités et passent du côté obscur :)
Tu as tout à fait raison sur les points que tu évoques je pense.
Pour ma part, je déplore fortement la non-popularité des langages fortement typés. Le duck typing de python par exemple me semble très nocif pour la maintenabilité à long terme d'une application. Bon, le random typing de PHP, c'est pire, n'en parlons pas...
Pour l'absence d'IDE "potable", c'est lié à deux choses :
- les choix personnels : tout le monde n'apprécie pas un monstre tel eclipse ou netbeans. Pour ma part, j'aime bien KDevelop mais surtout Qt Creator, qui est léger et contient juste ce qu'il me faut.
- l'absence de typage rendant très délicates des opérations comme le refactoring. Soient deux classes A et B contenant chacune une méthode test. Si tu renommes A::test en A::plop, comment s'assurer que ce qui est renommé dans le code est bien une instance de A et pas une instance de B ?
Par contre à l'inverse, la plupart des frameworks dans des langages avec un typage fort vont être imbuvables ou avoir une architecture ultra compliquée (je pense que c'est lié à la fois techniquement et par "l'état d'esprit" des développeurs dans ces langages)...
C'est le principal soucis des framework Web Java à ma connaissance... À quand le Java on Rails ? :) Ou le C+lons :)
J'ai mis un serveur à genoux avec moins que ça, oui... Grâce à des frameworks PHP pas optimisés du tout, c'est facile à faire...
Et une page d'accueil qui bouffe 2 secondes de CPU côté serveur (et avec les caches du framework activés), c'est pas la joie.
Au passage, je n'ai pas dit que c'est un mauvais choix, loin de là, je demande juste pourquoi Ruby On Rails en prenant en compte la réputation que j'en ai perçu, c'est tout. Si jugement il y a, c'est dans ton interprétation de mon commentaire, pas dans mon commentaire.
Heu, honnêtement, choisir un CMS ça a été considéré sérieusement pour Linuxfr ??
Vu les performances de ces trucs en général... (j'ai bouffé du drupal, je veux plus jamais y toucher)
Merci pour cette explication de l'abandon de Templeet... Ça fait des années qu'on nous dit que Templeet pour Linuxfr pose des problèmes, il est clair qu'il faut migrer un jour ou l'autre.
Par contre, pourquoi choisir Ruby on Rails ?
Est-ce un choix justifié techniquement, ou juste une préférence personnelle ?
J'ai souvent lu des critiques concernant les performances souvent mauvaises de Ruby on Rails, et pour un site comme LinuxFR je pense que les performances ça compte énormément. Actuellement, la navigation est très fluide, le site ne rame pas du tout, c'est un plaisir à utiliser. Si demain le site devenait plus lent, ce serait une réelle régression...
À titre personnel, je ne contribuerai pas à un LinuxFR en Ruby on Rails tout simplement parce que je n'aime pas le développement web et que je ne connais ni Ruby ni Ruby On Rails.
au fait, le serveur espagnol qui permet de définir des zones et de sauvegarder en local toutes les cartes, toutes selon le niveau, de gmaps, fonctionnent toujours...
Et ?
Ça sert à rien pour le projet OSM (ça serait totalement illégal).
Et ça reste des données non éditables, en raster uniquement, alors qu'avec un simple maposmatic tu peux avoir une carte en vectoriel avec par exemple un index des rues...
Je suis pas certain qu'on puisse parler de pourcentages de priorité. En tout cas, à ma connaissance, c'est pas implémenté sous Linux. Au mieux tu as une liste fixe de niveaux de priorité, et c'est heureusement suffisant pour normalement tous les cas.
Pour clarifier : choisir ce qui est prioritaire : un utilisateur lambda, les services du système...
Par exemple tu peux imaginer rendre SSH super prioritaire, avoir un utilisateur guest le moins prioritaire possible, ton utilisateur à toi être plus prioritaire que certains services à la con...
Bref, tu peux configurer et choisir.
Ben de toute façon ce que tu suggères n'est tout simplement pas viable.
Je vois mal un mplayer sur un film HD, un jeu, un compilateur ou autre tenir avec moins de 5% du CPU (l'init a quand même une cinquantaine d'enfants chez moi).
La séparation en groupe est suffisante, sans allouer de manière fixe des portions de CPU ce qui serait un énorme retour en arrière...
Comme déjà expliqué : un cgroup par fils lancé par l'init. Ensuite tu peux imaginer compter les fils de chaque groupe pour déterminer si il faut plus ou moins de CPU pour ce groupe, mais dans ce cas c'est risquer qu'une fork bomb prenne tout le CPU pour elle toute seule...
Paquet cgroup-bin (pour debian et dérivés, pour Fedora c'est dans un autre paquet il me semble), tu as la commande cgexec.
Tu dois pour l'utiliser
1) configurer un ensemble de groupes (en les nommant, par exemple un groupe "compilation barbare", un groupe "service ultra prioritaire"...) : fichiers de configuration /etc/cgrules.conf et /etc/cgconfig.conf
2) cgexec -g cpu,memory:compilation_barbare make -j 2000000
Bien sûr, tu peux imaginer créer à la volée des groupes, à l'aide de cgcreate.
Rien ne prouve que ce patch sera inclus dans le noyau. Comme expliqué plus haut, ce patch fait quelque chose qui devrait peut être être fait par l'espace utilisateur et par des outils comme systemd ou autre.
Est-il nécessaire d'altérer le noyau pour cela ?
Lennart Pottering a prouvé qu'un équivalent est faisable très facilement avec quelques lignes dans le .bashrc : cela ne suffit-il pas à diminier l'intérêt de ce patch par rapport à une solution configurable plus finement ?
systemd n'a pas l'intention d'utiliser les cgroups, il les utilise, point.
Sur ma debian j'ai activé systemd, et maintenant la vie me sourit j'ai plein de cgroups :)
La commande systemd-cgls liste les cgroups utilisés sous forme d'arborescence.
En voici un court extrait :
├ 2 [kthreadd]
├ 3 [ksoftirqd/0]
├ 6 [migration/0]
(blabla noyau)
├ 16896 [kworker/u:2]
├ user
│ ├ root
│ │ └ 5c
│ │ ├ 3586 su
│ │ ├ 3588 bash
│ └ moi
│ └ 2c
│ ├ 2193 -:0
│ ├ 2716 /bin/sh /usr/bin/startkde
│ ├ 2747 /usr/bin/ssh-agent /usr/bin/ck-launch-session /usr/bin/dbus-launch --exit-with-session /usr/bin/startkde
│ ├ 2750 /usr/bin/dbus-launch --exit-with-session /usr/bin/startkde
(blabla mes processus)
└ systemd-1
├ 1 /bin/systemd
├ nfs-common.service
│ └ 15777 /sbin/rpc.statd
├ portmap.service
│ └ 15724 /sbin/portmap
├ kdm.service
│ ├ 1889 /usr/bin/kdm -config /var/run/kdm/kdmrc
│ ├ 1907 /usr/bin/X :0 vt7 -br -nolisten tcp -auth /var/run/xauth/A:0-QsrSzb
│ ├ 2697 dbus-launch --autolaunch 9d930b78559f3c00ceac5bb1478de8d9 --binary-syntax --close-stderr
│ └ 2698 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
(blabla les services système)
Les cgroups permettent/permettront de faire tout ce qu'on a dit de trop cool, mais par contre, j'avoue ne pas savoir les utiliser (même pas eu le temps de lire la doc).
Sur son blog, Lennart parle notamment des options OOMScoreAdjust, CPUSchedulingPolicy... dans les fichiers de configuration des services pour systemd. Ce qui apporte, il me semble, une flexibilité considérable.
Bien sûr, les plus malins diront "un double fork, et mon processus détaché sort du contrôle de systemd".... C'est pour ça que les cgroups sont utilisés : les enfants, même détachés, restent dans le cgroup.
Les cgroups sont utilisés intelligemment il me semble dans systemd, "l'init killer" développé par Lennart Poettering dont on a parlé quelques commentaires plus haut... Chaque service son group, chaque utilisateur son cgroup, et tout le monde est content... On peut ainsi limiter la RAM, le CPU, les IO d'un service, rendre prioritaire l'utilisateur ou les services du système...
En fait, chaque xterm va lancer un bash qui va arriver dans un groupe séparé.
Donc le make -j 64 est dans un groupe distinct du reste de l'interface, et voilà...
Le scheduleur, je suppose, va faire attention à ce que chaque groupe ait un bout "suffisant" de CPU pour son travail, alors que si tout le monde est dans un groupe, ben à cause du make -j 64, y'aura 64 + n processus voulant le processeur, et le scheduleur ne sait pas qui "favoriser" et donne autant que possible à chaque processus, tout simplement...
D'ailleurs, peut-on émuler le patch noyau avec des commandes shell ? Les cgroups peuvent être configuré avec un système de fichier virtuel.
systemd est parfaitement capable de faire ça il me semble.
D'ailleurs j'ai vu des discussions sur l'intérêt de ce patch si l'espace utilisateur ne peut pas faire tout plus finement...
Mais il serait bon de plutôt les comparer a un gpu Intel, dont les pilotes libres sont plus abouti (je n'ai pas d'intel, je spécule peu être...?)
Le soucis c'est que les IGP Intel sont par nature lents déjà, mais qu'en plus, les pilotes Linux sont deux à trois fois plus lents que les pilotes windows !
Par contre, en 2D, ils sont très bons.
Pour information, petit benchmark de Phoronix sur ce sujet : http://www.phoronix.com/scan.php?page=news_item&px=ODIwM(...)
Aucun commentaire n'est nécessaire je pense...
Tu as tout à fait raison, oui.
Le support très avancé, et avec le niveau d'optimisation requis, de la 3D prendra vraiment très longtemps, et d'ici là, les technologies auront sûrement suffisamment évolué pour que des années de travail soient à nouveau requises pour atteindre le niveau requis...
Dans le cas du pilote nouveau, il faut noter qu'un fork de la partie 3D a été créé par une entreprise motivée par la réalisation d'un système très performant, plus performant que celui de nVidia, pour les G80 et supérieur. Reste à voir ce que cela donnera. Ils prévoient le support de l'OpenGL4 pour 2011/2012, ce qui, vu l'état actuel des choses, semble être un objectif bien difficile à atteindre.
Hoo une blague...
Petit rappel : les développeurs des pilotes libres n'ont jamais promis d'avoir les performances des pilotes propriétaires, et si ils approchent de 50% des perfs des pilotes propriétaires ça sera déjà un mini-exploit.
Les performances des pilotes propriétaires sont le fruit de plusieurs années d'optimisation, orientée par les nombreux jeux et logiciels qu'ils font tourner.
Par contre, là où ils peuvent briller, c'est sur le support de la 2D, le support de toutes les technologies présentes dans le serveur X...
Déjà, comme dit avant, on perd beaucoup du charme des ARM.
De plus, la consommation électrique de l'Atom reste bien au dessus de la consommation d'un ARM.
Enfin, ces systèmes reposent sur une puce graphique intel renommée : le GMA 3150 est un i945 renommé et intégré au processeur. Et si tu veux faire un média center avec ça, aucune chance, les performances graphiques sont tout simplement ridicules.
Les ARM eux sont souvent fournis avec des puces graphiques bien plus performantes. Par contre, autre problème dans ce cas : trouver des pilotes fonctionnels... Ça c'est une autre histoire...
# OpenOffice.org sur android ?
Posté par Pinaraf . En réponse au journal SoftMaker Office 2010 bientôt pour Android, la Bêta pour très bientôt. Évalué à 2.
Ce n'est pas qu'une question de poids. Vu la puissance des derniers appareils sortis...
Premier point, OpenOffice.org n'est pas conçu pour une interface de type smartphone ou un écran trop petit (pour un netbook, c'est donc limite)
Deuxième point, Android est trop différent d'une plateforme Linux traditionnelle pour qu'une simple recompilation suffise pour y porter OpenOffice.org : il faudrait installer un serveur X, revoir aussi pas mal d'éléments de l'interface graphique... Porter proprement OpenOffice.org sur Android sera(it) un travail titanesque (en jouant avec le NDK, et en réécrivant pas mal de morceaux d'OpenOffice.org, ça doit être faisable), je ne pense pas que beaucoup de volontaires se présentent pour le réaliser...
[^] # Re: .
Posté par Pinaraf . En réponse au journal Pourquoi réécrire LinuxFr.org ?. Évalué à 2.
[^] # Re: .
Posté par Pinaraf . En réponse au journal Pourquoi réécrire LinuxFr.org ?. Évalué à 4.
Forcément après quand ils voient <?php echo "hello world"; ?> ils sont excités et passent du côté obscur :)
[^] # Re: .
Posté par Pinaraf . En réponse au journal Pourquoi réécrire LinuxFr.org ?. Évalué à 1.
Pour ma part, je déplore fortement la non-popularité des langages fortement typés. Le duck typing de python par exemple me semble très nocif pour la maintenabilité à long terme d'une application. Bon, le random typing de PHP, c'est pire, n'en parlons pas...
Pour l'absence d'IDE "potable", c'est lié à deux choses :
- les choix personnels : tout le monde n'apprécie pas un monstre tel eclipse ou netbeans. Pour ma part, j'aime bien KDevelop mais surtout Qt Creator, qui est léger et contient juste ce qu'il me faut.
- l'absence de typage rendant très délicates des opérations comme le refactoring. Soient deux classes A et B contenant chacune une méthode test. Si tu renommes A::test en A::plop, comment s'assurer que ce qui est renommé dans le code est bien une instance de A et pas une instance de B ?
Par contre à l'inverse, la plupart des frameworks dans des langages avec un typage fort vont être imbuvables ou avoir une architecture ultra compliquée (je pense que c'est lié à la fois techniquement et par "l'état d'esprit" des développeurs dans ces langages)...
C'est le principal soucis des framework Web Java à ma connaissance... À quand le Java on Rails ? :) Ou le C+lons :)
[^] # Re: Et le choix de Ruby on Rails ?
Posté par Pinaraf . En réponse au journal Pourquoi réécrire LinuxFr.org ?. Évalué à 2.
Et une page d'accueil qui bouffe 2 secondes de CPU côté serveur (et avec les caches du framework activés), c'est pas la joie.
Au passage, je n'ai pas dit que c'est un mauvais choix, loin de là, je demande juste pourquoi Ruby On Rails en prenant en compte la réputation que j'en ai perçu, c'est tout. Si jugement il y a, c'est dans ton interprétation de mon commentaire, pas dans mon commentaire.
[^] # Re: Et le choix de Ruby on Rails ?
Posté par Pinaraf . En réponse au journal Pourquoi réécrire LinuxFr.org ?. Évalué à 10.
Pareil pour Synphony.
Pareil pour tout framework bien foutu quoi...
[^] # Re: Et le choix de Ruby on Rails ?
Posté par Pinaraf . En réponse au journal Pourquoi réécrire LinuxFr.org ?. Évalué à 1.
Vu les performances de ces trucs en général... (j'ai bouffé du drupal, je veux plus jamais y toucher)
# Et le choix de Ruby on Rails ?
Posté par Pinaraf . En réponse au journal Pourquoi réécrire LinuxFr.org ?. Évalué à 10.
Par contre, pourquoi choisir Ruby on Rails ?
Est-ce un choix justifié techniquement, ou juste une préférence personnelle ?
J'ai souvent lu des critiques concernant les performances souvent mauvaises de Ruby on Rails, et pour un site comme LinuxFR je pense que les performances ça compte énormément. Actuellement, la navigation est très fluide, le site ne rame pas du tout, c'est un plaisir à utiliser. Si demain le site devenait plus lent, ce serait une réelle régression...
À titre personnel, je ne contribuerai pas à un LinuxFR en Ruby on Rails tout simplement parce que je n'aime pas le développement web et que je ne connais ni Ruby ni Ruby On Rails.
[^] # Re: Essai
Posté par Pinaraf . En réponse au journal Microsoft soutient et contribue à Open Street Map. Évalué à 2.
Et ?
Ça sert à rien pour le projet OSM (ça serait totalement illégal).
Et ça reste des données non éditables, en raster uniquement, alors qu'avec un simple maposmatic tu peux avoir une carte en vectoriel avec par exemple un index des rues...
[^] # Re: Gain sur un environnement de bureau n'utilisant pas de terminaux ?
Posté par Pinaraf . En réponse à la dépêche Patch pour le noyau Linux améliorant l'interactivité entre les applications console et Xorg. Évalué à 2.
[^] # Re: Cgroups
Posté par Pinaraf . En réponse à la dépêche Patch pour le noyau Linux améliorant l'interactivité entre les applications console et Xorg. Évalué à 3.
Par exemple tu peux imaginer rendre SSH super prioritaire, avoir un utilisateur guest le moins prioritaire possible, ton utilisateur à toi être plus prioritaire que certains services à la con...
Bref, tu peux configurer et choisir.
[^] # Re: Gain sur un environnement de bureau n'utilisant pas de terminaux ?
Posté par Pinaraf . En réponse à la dépêche Patch pour le noyau Linux améliorant l'interactivité entre les applications console et Xorg. Évalué à 2.
Je vois mal un mplayer sur un film HD, un jeu, un compilateur ou autre tenir avec moins de 5% du CPU (l'init a quand même une cinquantaine d'enfants chez moi).
La séparation en groupe est suffisante, sans allouer de manière fixe des portions de CPU ce qui serait un énorme retour en arrière...
[^] # Re: Gain sur un environnement de bureau n'utilisant pas de terminaux ?
Posté par Pinaraf . En réponse à la dépêche Patch pour le noyau Linux améliorant l'interactivité entre les applications console et Xorg. Évalué à 2.
[^] # Re: Spoile !
Posté par Pinaraf . En réponse à la dépêche Patch pour le noyau Linux améliorant l'interactivité entre les applications console et Xorg. Évalué à 7.
Tu dois pour l'utiliser
1) configurer un ensemble de groupes (en les nommant, par exemple un groupe "compilation barbare", un groupe "service ultra prioritaire"...) : fichiers de configuration /etc/cgrules.conf et /etc/cgconfig.conf
2) cgexec -g cpu,memory:compilation_barbare make -j 2000000
Bien sûr, tu peux imaginer créer à la volée des groupes, à l'aide de cgcreate.
[^] # Re: Gain sur un environnement de bureau n'utilisant pas de terminaux ?
Posté par Pinaraf . En réponse à la dépêche Patch pour le noyau Linux améliorant l'interactivité entre les applications console et Xorg. Évalué à 5.
[^] # Re: Spoile !
Posté par Pinaraf . En réponse à la dépêche Patch pour le noyau Linux améliorant l'interactivité entre les applications console et Xorg. Évalué à 6.
Est-il nécessaire d'altérer le noyau pour cela ?
Lennart Pottering a prouvé qu'un équivalent est faisable très facilement avec quelques lignes dans le .bashrc : cela ne suffit-il pas à diminier l'intérêt de ce patch par rapport à une solution configurable plus finement ?
[^] # Re: Cgroups
Posté par Pinaraf . En réponse à la dépêche Patch pour le noyau Linux améliorant l'interactivité entre les applications console et Xorg. Évalué à 8.
Sur ma debian j'ai activé systemd, et maintenant la vie me sourit j'ai plein de cgroups :)
La commande systemd-cgls liste les cgroups utilisés sous forme d'arborescence.
En voici un court extrait :
├ 2 [kthreadd]
├ 3 [ksoftirqd/0]
├ 6 [migration/0]
(blabla noyau)
├ 16896 [kworker/u:2]
├ user
│ ├ root
│ │ └ 5c
│ │ ├ 3586 su
│ │ ├ 3588 bash
│ └ moi
│ └ 2c
│ ├ 2193 -:0
│ ├ 2716 /bin/sh /usr/bin/startkde
│ ├ 2747 /usr/bin/ssh-agent /usr/bin/ck-launch-session /usr/bin/dbus-launch --exit-with-session /usr/bin/startkde
│ ├ 2750 /usr/bin/dbus-launch --exit-with-session /usr/bin/startkde
(blabla mes processus)
└ systemd-1
├ 1 /bin/systemd
├ nfs-common.service
│ └ 15777 /sbin/rpc.statd
├ portmap.service
│ └ 15724 /sbin/portmap
├ kdm.service
│ ├ 1889 /usr/bin/kdm -config /var/run/kdm/kdmrc
│ ├ 1907 /usr/bin/X :0 vt7 -br -nolisten tcp -auth /var/run/xauth/A:0-QsrSzb
│ ├ 2697 dbus-launch --autolaunch 9d930b78559f3c00ceac5bb1478de8d9 --binary-syntax --close-stderr
│ └ 2698 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
(blabla les services système)
Les cgroups permettent/permettront de faire tout ce qu'on a dit de trop cool, mais par contre, j'avoue ne pas savoir les utiliser (même pas eu le temps de lire la doc).
Sur son blog, Lennart parle notamment des options OOMScoreAdjust, CPUSchedulingPolicy... dans les fichiers de configuration des services pour systemd. Ce qui apporte, il me semble, une flexibilité considérable.
Bien sûr, les plus malins diront "un double fork, et mon processus détaché sort du contrôle de systemd".... C'est pour ça que les cgroups sont utilisés : les enfants, même détachés, restent dans le cgroup.
[^] # Re: Cgroups
Posté par Pinaraf . En réponse à la dépêche Patch pour le noyau Linux améliorant l'interactivité entre les applications console et Xorg. Évalué à 3.
[^] # Re: Gain sur un environnement de bureau n'utilisant pas de terminaux ?
Posté par Pinaraf . En réponse à la dépêche Patch pour le noyau Linux améliorant l'interactivité entre les applications console et Xorg. Évalué à 7.
Donc le make -j 64 est dans un groupe distinct du reste de l'interface, et voilà...
Le scheduleur, je suppose, va faire attention à ce que chaque groupe ait un bout "suffisant" de CPU pour son travail, alors que si tout le monde est dans un groupe, ben à cause du make -j 64, y'aura 64 + n processus voulant le processeur, et le scheduleur ne sait pas qui "favoriser" et donne autant que possible à chaque processus, tout simplement...
[^] # Re: Gain sur un environnement de bureau n'utilisant pas de terminaux ?
Posté par Pinaraf . En réponse à la dépêche Patch pour le noyau Linux améliorant l'interactivité entre les applications console et Xorg. Évalué à 3.
systemd est parfaitement capable de faire ça il me semble.
D'ailleurs j'ai vu des discussions sur l'intérêt de ce patch si l'espace utilisateur ne peut pas faire tout plus finement...
[^] # Re: UT2004 passe bien
Posté par Pinaraf . En réponse au journal QUAKE Wars et Mesa. Évalué à 2.
Le soucis c'est que les IGP Intel sont par nature lents déjà, mais qu'en plus, les pilotes Linux sont deux à trois fois plus lents que les pilotes windows !
Par contre, en 2D, ils sont très bons.
Pour information, petit benchmark de Phoronix sur ce sujet :
http://www.phoronix.com/scan.php?page=news_item&px=ODIwM(...)
Aucun commentaire n'est nécessaire je pense...
[^] # Re: Ati et les specs
Posté par Pinaraf . En réponse au journal QUAKE Wars et Mesa. Évalué à 2.
Le support très avancé, et avec le niveau d'optimisation requis, de la 3D prendra vraiment très longtemps, et d'ici là, les technologies auront sûrement suffisamment évolué pour que des années de travail soient à nouveau requises pour atteindre le niveau requis...
Dans le cas du pilote nouveau, il faut noter qu'un fork de la partie 3D a été créé par une entreprise motivée par la réalisation d'un système très performant, plus performant que celui de nVidia, pour les G80 et supérieur. Reste à voir ce que cela donnera. Ils prévoient le support de l'OpenGL4 pour 2011/2012, ce qui, vu l'état actuel des choses, semble être un objectif bien difficile à atteindre.
[^] # Re: Ati et les specs
Posté par Pinaraf . En réponse au journal QUAKE Wars et Mesa. Évalué à 2.
Petit rappel : les développeurs des pilotes libres n'ont jamais promis d'avoir les performances des pilotes propriétaires, et si ils approchent de 50% des perfs des pilotes propriétaires ça sera déjà un mini-exploit.
Les performances des pilotes propriétaires sont le fruit de plusieurs années d'optimisation, orientée par les nombreux jeux et logiciels qu'ils font tourner.
Par contre, là où ils peuvent briller, c'est sur le support de la 2D, le support de toutes les technologies présentes dans le serveur X...
[^] # Re: Atom?
Posté par Pinaraf . En réponse au journal Enfin un serveur basse consommation?. Évalué à 2.
[^] # Re: Atom?
Posté par Pinaraf . En réponse au journal Enfin un serveur basse consommation?. Évalué à 4.
De plus, la consommation électrique de l'Atom reste bien au dessus de la consommation d'un ARM.
Enfin, ces systèmes reposent sur une puce graphique intel renommée : le GMA 3150 est un i945 renommé et intégré au processeur. Et si tu veux faire un média center avec ça, aucune chance, les performances graphiques sont tout simplement ridicules.
Les ARM eux sont souvent fournis avec des puces graphiques bien plus performantes. Par contre, autre problème dans ce cas : trouver des pilotes fonctionnels... Ça c'est une autre histoire...