- A forcer Novell, RedHat etc a se bouger les fesses pour ameliorer eux aussi l'aspect Desktop de Linux qui avait, ne l'oublions pas, ete totalement abandonne par ces deux boites. Ce qui sous entend tous le cote user friendly et documentations.
Cette dernière affirmation me surprend un peu. Pour Fedora je ne m'affirme pas trop, mais SuSE Linux/openSUSE a toujours eu une longueur d'avance pour le côté "user-friendly" (ne serait-ce que par YaST, ou l'installateur graphique). On peut aussi difficilement dire que la doc officielle ait été abandonnée (un gros pavé de 800+ pages était livré dans la boite, actuellement il n'y a plus qu'un petit de 250-300 pages avec un important complément PDF).
Le seul truc qui manque à la plupart des distrib "grand public" pour être au niveau d'ubuntu, c'est son marketing et ses utilisateurs kikoolol.
Alors c'est bien qu'Ubuntu remplisse ce rôle "intermédiaire".
Il y a plusieurs façons de remplir ce rôle intermédiaire :
- Proposer des drivers proprios.
- Proposer des drivers proprios en attendant et participer en paralèlle (humainement, financièrement) au développement d'une solution libre.
L'une de ces solutions est "responsable" envers le Libre, l'autre beaucoup moins.
Je ne pense pas que ca soit comparable. Novell c'est historiquement un grand acteur du monde proprio depuis 25 ans (Netware par exemple) qui se met de plus en plus au libre. Sa branche "opensource" (représentées par les départements R&D en gros) est encore très minoritaire (10% à 15% du bénéf de l'entreprise), bien qu'elle progresse vite et que de plus en plus des autres départements de Novell s'y "greffent" au fil du temps.
Si tu veux vraiment comparer, sache que toute l'infrastructure utilisée pour openSUSE est libre (à commencer par le Build Service, pièce majeure du projet), c'est identique pour Fedora.
Oui, Canonical n'a pas de "business model" viable. Mais le fait est que Shuttleworth a les moyens de payer 150 à 200 personnes qui bossent sur du packaging et un peu d'intégration, c'est plus que Mandriva (~60 personnes) qui en font bien plus et qui "en bavent" pour ainsi dire.
Shuttleworth n'a pas pour vocation de contribuer au "coeur" du système.
Passons sur l'attaque de Canonical, que je trouve totalement déplacée même si je ne porte pas Shuttleworth dans mon coeur. Egalement je pense que l'on sait tous que Canonical n'a pas pour vocation de contribuer au "coeur" du système même s'ils en ont les moyens.
Un passage intéressant du poste de Kroah et qui n'a pas été abordé dans le journal est la distinction des différents types d'acteurs, et leur manière de contribuer :
- Les distrib "entreprises", où le flux de contributions se fait principalement "downstream", par des patchs et des fix de sécurité.
- Les distrib "communautaires" (sponsorisées ou non), où le flux de contributions se fait principalement "upstream", parce que les devs savent qu'ils devront réappliquer leurs modifications à la fin du cylce de release assez court.
- Enfin, les distrib "communautaires" qui se basent sur une autre distribution (ubuntu et centos sont citées, meme si je pense que centos n'entre pas dans cette catégorie). Celles-ci ont une "couche d'abstraction" supplémentaire (debian pour ubuntu), qui représente un "obstacle" supplémentaire à la contribution upstream puisqu'elles dépendent fortement de la distibution intermédiaire.
Il serait intéressant de voir à quel point cette dernière catégorie correspond (ou correspond encore) à Canonical/Ubuntu. Mon impression est que ça l'était fortement dans le passé, avec beaucoup de critiques associées (notamment Launchpad qui est un peu une "barrière" pour l'envoi de patchs aux projets upstream).
Mais j'ai aussi l'impression que ça change un peu, justement à cause de ces critiques, et qu'Ubuntu est "moins" basée sur Debian actuellement (syncro régulière de seulement une partie des paquets et pas tous, par exemple).
Egalement, je ne sais pas si l'"expérience Ubuntu" est toujours positive. Quand je vois certain posts (au hasard, celui là : http://ploum.frimouvy.org/?194-hardy-is-a-hard-time), j'ai aussi l'impression que c'est à double tranchant.
Toutes les distro ne sont pas encore passées à QT 4 donc ça peut être un problème.
Ca fait 3 ans que Qt4 est sorti maintenant, j'imagine que la plupart des distro ont eu le temps de faire un paquet...
En plus "un skin QT ayant le look de Gnome" ça veut rien dire. Au pire ça utilise QT-GTK qui permet de mettre un style GTK comme style QT mais sinon je ne vois pas bien comment ça va s'intégrer superbement partout. Et puis y'a pas que le style graphique, y'a aussi les dialogues d'ouverture/enregistrement qui changent fortement entre QT et GTK. Ou alors j'ai pas bien compris...
C'est inclut nativement dans Qt maintenant. Une appli Qt au sein d'un environnement Gnome "mimique" l'aspect GTK.
Blablabla.. arrête d'écouter les moules Linuxfriennes délirer pour un oui pour un non.
Entame de longues, pénibles, couteuses procédures judiciaires parce que le spammeur t'as spammé comme des millions d'autres. Ou fait justice. Tu te marreras bien et en plus, une occasion en or comme ça ne se présente pas tous les jours :)
PS: Ne lui donne pas la raison du pourquoi sa base de données s'est vidée, file nous le lien pour la suite plutôt. Les moules veulent jouer aussi :D
Urpmi, Yum et autre Apt sont plus ou moins similaires : ils doivent gérer un compromis entre la rapidité de la résolution du problème de dépendances et la qualité de cette même solution.
Je me demande par contre comment se débrouillerait ZYpp sur les limites rencontrées par Apt dans la résolution des Sudoku, sachant qu'il utilise un solveur SAT qui est complet (il ne trouve pas une solution possible, mais il trouve la meilleure solution possible dans un temps très raisonnable.)
Tout dépend de ce que tu définis par "quelqu'un" et "utiliser" :)
En ce qui concernent la création de paquets, les statistiques actuelles du dépôt central openSUSE donnent : There are now 3716 projects, 48754 packages, 7204 repositories and 8606 confirmed users.
toutes achitectures (i586, x86_64, ia64) et toutes distributions confondues (mais surtout openSUSE).
Egalement, rien n'empêche n'importe qui (distribution, ou developpeur d'un projet quelconque) d'installer une copie locale sur sa ferme de compil/son ordinateur personnel, puique les sources du Build Service sont disponibles librement (mais on perd l'avantage de l'utilisation directe de la ferme de compilation du projet openSUSE).
Le but premier du Build Service, outre de creer des paquets pour plusieurs distrib facilement, est de dynamiser les interactions entre les projets (en recompilant automatiquement les paquets lors que c'est nécessaire), tout en ayant un lien direct avec les sources upstream.
Egalement, le BS peut s'utiliser de façon décentralisée, en "pointant" vers un Build Service central (celui d'openSUSE par défaut), les différents projets restant liés entre eux.
Les statistiques exactes sont donc difficiles à obtenir, et savoir "qui" l'utilise (et dans quel but?) est chose impossible. Mais aucune distribution majeure ne l'utilise à ma connaissance, chacune ayant son propre système local.
Mon petit doigt me dis que quelque chose qui sert à ça existe déjà : le Build Service openSUSE, qui est déjà largement utilisé (entre autres choses) pour créer des Backports pour openSUSE, mais qui permet aussi de le faire pour d'autres distributions.
C'est pour l'heure assez peu utilisé en dehors d'openSUSE, et c'est bien dommage à mon avis.
Ce qui change rien au fait que limite ultime il y a. Et cette
Quantité extractible pour pas chère <= Quantité de pétrole crée aucours des ages.
T'auras beau mettre autant d'argent et d'énergie dans l'extraction, quand il y en a plus ... il y en a plus.
Les commentaires précédents mettent surtout en valeurs que cette limite "ultime" n'a aucun sens : on ne l'atteindra jamais.
Si tu considères que chaque molécule d'hydrocarbure existante sur terre fait partie de cette réserve, alors oui, on peut presque dire que les réserves de pétroles sont... illimités, puisque les réserves sont exploitables aujourd'hui, demain ou alors.. jamais. Il y a, en absolu, du pétrole en abondance, et il y en aura toujours.
La notion de "réserves exploitables" est bien plus complexe que cela. Egalement, la disponibilité du pétrole "peu cher "est une toute autre histoire.
Sinon, oui, je connais la théorie du pic de Hubbert. Je sais aussi qu'il existe plusieurs autres facteurs dans la détermination des réserves exploitables. Voir par exemple : http://www.erdoel-vereinigung.ch/fr/oilfacts/Erdoelangebot/P(...) - oui, c'est un site de l'Union pétrolière suisse, mais il a le mérite d'être assez explicite et de ne pas avoir une approche trop "simpliste" sur ce sujet qui est très complexe.
Et sinon, j'ai vraiment fait une pique sur l'UE, hu ?
(note: je suis le premier à me méfier des données issues des compagnies pétrolières, j'ai fait mes études dans le domaine de l'environnement)
Ce qui n'est pas tout a fait vrai : il y en aura (presque) toujours, la question est "est ce que c'est rentable de l'exploiter" : cout de l'exploitation vs capacité que l'on peut produire.
C'est pour ca que les sable bitumeux deviennent rentables à produire (alors qu'ils consomment une quantité importante d'énergie pour pouvoir les extraires, en plus de polluer la terre environnante).
C'est tout à fait cela, on parle ainsi de "réserves élastiques" Plus le pétrole est cher, plus il devient rentable d'exploiter du pétrole qui est moins facile d'accès, et plus il y a de pétrole disponible.
On arrive ainsi au "paradoxe des réserves", en toute contradiction avec l'offre de la loi et la demande.
Aussi, la "limite physique" n'est pas la quantité limitée de pétrole, mais plutôt l'énergie investie pour l'extraction. Lorsque qu'il faudra un baril d'énergie pour extraire un baril de pétrole, on arrêtera l'extraction, quel que soit le prix du pétrole sur le marché. Mais auparavant, les paramètres "d'optimisation des techiques d'extraction", "nouvelles techniques d'extraction" ou "d'exploitation de reserves alternatives" entrent en jeu.
Posté par Spyhawk .
En réponse au journal SELinux.
Évalué à 2.
Effectivement ! Ce sera proposé en parallèle d'AppArmor, qui sera toujours le système de sécurité par défaut. On peut se demander pour combien de temps encore..
J'ai donné mon opinon en faveur de nVidia sachant que :
- l'auteur du journal veut acheter une carte assez haut de gamme
- l'auteur du journal a besoin d'une accélération 3d fonctionnel (avec quelques fonctions récentes)
Au lieu de faire un sermon libriste (que tout le monde connait je pense), peut être est-ce que tu peux donner tes retours avec les drivers libres de chez ATI ?
- Les drivers libres donnent-ils des performances suffisantes par rapport aux besoins de l'auteur du journal ?
- Sinon, les specs déjà libérées (ou qui le seront prochainement) donneront-elles des drivers 3D fonctionnels, par rapport aux besoins de l'auteur du journal, à court terme (quelques mois) ?
Je ne pense pas, mais tes réponses m'intéressent grandement. Si je me trompe je serais heureux de l'apprendre :)
Si tu désires des fonctionnalités 3D poussées, alors je crois qu'on peut déjà exclure d'office les (projets de) drivers libres ATI et nVidia, qui ne fourniront pas de fonctions 3D équivalentes avant plusieurs mois (voir années?). Bref, t'auras surement le besoin d'acheter une nouvelle carte d'ici là.
Historiquement, j'ai toujours conseillé nVidia, parce que "ça marchait mieux" avec les drivers closed-source. Aussi, comme tu le cites, ATI a fait pas mal de progrès dernièrement, et rattrapé une partie de son retard. Mais selon un article en anglais paru récemment en journal de seconde page (et dont je ne retrouve plus le lien :/ si l'auteur du journal passe par ici..), nVidia propose toujours la meilleure implémentation d'openGL.
Jusqu'à il y a quelques jours, je t'aurais dis "Je ne sais pas", parce que les derniers drivers nVidia ont eu pas mal de soucis avec KDE 4 notamment, pendant une assez longue période. Cependant, selon les tous derniers drivers 177.68 Beta du 21 août :
Improved GPU video memory management coordination between the
NVIDIA X driver and OpenGL implementation; this should
improve performance with e.g. the KDE4 OpenGL compositing
manager.
Heu, juste pour modérer un peu le propos (mais pas le problème :)).
GMail offre un service payant aux entreprises (j'ai une adresse qui utilise ça).
Grosso modo, c'est GMail, mais avec le logo de l'entreprise, pas de pub, et pas de GTalk non plus.
Donc oui, c'est intéressant pour une PME : service mail à moindre coût. Reste le problème de la confidentialité (y a-t'il une clause dans le contrat à ce sujet?) et des bugs... un peu plus qu'ennuyeux.
[^] # Re: Notre incommensurable bêtise
Posté par Spyhawk . En réponse au journal La controverse Canonical. Évalué à 2.
http://tech.slashdot.org/article.pl?sid=08/07/14/1245204&(...)
[^] # Re: En Pourcentage (plus parlant pour certains)
Posté par Spyhawk . En réponse au journal La controverse Canonical. Évalué à 5.
Cette dernière affirmation me surprend un peu. Pour Fedora je ne m'affirme pas trop, mais SuSE Linux/openSUSE a toujours eu une longueur d'avance pour le côté "user-friendly" (ne serait-ce que par YaST, ou l'installateur graphique). On peut aussi difficilement dire que la doc officielle ait été abandonnée (un gros pavé de 800+ pages était livré dans la boite, actuellement il n'y a plus qu'un petit de 250-300 pages avec un important complément PDF).
Le seul truc qui manque à la plupart des distrib "grand public" pour être au niveau d'ubuntu, c'est son marketing et ses utilisateurs kikoolol.
[^] # Re: Autre mesure...
Posté par Spyhawk . En réponse au journal La controverse Canonical. Évalué à 2.
Il y a plusieurs façons de remplir ce rôle intermédiaire :
- Proposer des drivers proprios.
- Proposer des drivers proprios en attendant et participer en paralèlle (humainement, financièrement) au développement d'une solution libre.
L'une de ces solutions est "responsable" envers le Libre, l'autre beaucoup moins.
[^] # Re: Autre mesure...
Posté par Spyhawk . En réponse au journal La controverse Canonical. Évalué à 2.
Si tu veux vraiment comparer, sache que toute l'infrastructure utilisée pour openSUSE est libre (à commencer par le Build Service, pièce majeure du projet), c'est identique pour Fedora.
[^] # Re: Distrib based on based on ?
Posté par Spyhawk . En réponse au journal La controverse Canonical. Évalué à 5.
Shuttleworth n'a pas pour vocation de contribuer au "coeur" du système.
# Distrib based on based on ?
Posté par Spyhawk . En réponse au journal La controverse Canonical. Évalué à 2.
Un passage intéressant du poste de Kroah et qui n'a pas été abordé dans le journal est la distinction des différents types d'acteurs, et leur manière de contribuer :
- Les distrib "entreprises", où le flux de contributions se fait principalement "downstream", par des patchs et des fix de sécurité.
- Les distrib "communautaires" (sponsorisées ou non), où le flux de contributions se fait principalement "upstream", parce que les devs savent qu'ils devront réappliquer leurs modifications à la fin du cylce de release assez court.
- Enfin, les distrib "communautaires" qui se basent sur une autre distribution (ubuntu et centos sont citées, meme si je pense que centos n'entre pas dans cette catégorie). Celles-ci ont une "couche d'abstraction" supplémentaire (debian pour ubuntu), qui représente un "obstacle" supplémentaire à la contribution upstream puisqu'elles dépendent fortement de la distibution intermédiaire.
Il serait intéressant de voir à quel point cette dernière catégorie correspond (ou correspond encore) à Canonical/Ubuntu. Mon impression est que ça l'était fortement dans le passé, avec beaucoup de critiques associées (notamment Launchpad qui est un peu une "barrière" pour l'envoi de patchs aux projets upstream).
Mais j'ai aussi l'impression que ça change un peu, justement à cause de ces critiques, et qu'Ubuntu est "moins" basée sur Debian actuellement (syncro régulière de seulement une partie des paquets et pas tous, par exemple).
[^] # Re: Autre mesure...
Posté par Spyhawk . En réponse au journal La controverse Canonical. Évalué à 5.
Egalement, je ne sais pas si l'"expérience Ubuntu" est toujours positive. Quand je vois certain posts (au hasard, celui là : http://ploum.frimouvy.org/?194-hardy-is-a-hard-time), j'ai aussi l'impression que c'est à double tranchant.
[^] # Re: wiki down .. troll survives
Posté par Spyhawk . En réponse à la dépêche Sortie de VLC Media Player 0.9.2. Évalué à 6.
Ca fait 3 ans que Qt4 est sorti maintenant, j'imagine que la plupart des distro ont eu le temps de faire un paquet...
En plus "un skin QT ayant le look de Gnome" ça veut rien dire. Au pire ça utilise QT-GTK qui permet de mettre un style GTK comme style QT mais sinon je ne vois pas bien comment ça va s'intégrer superbement partout. Et puis y'a pas que le style graphique, y'a aussi les dialogues d'ouverture/enregistrement qui changent fortement entre QT et GTK. Ou alors j'ai pas bien compris...
C'est inclut nativement dans Qt maintenant. Une appli Qt au sein d'un environnement Gnome "mimique" l'aspect GTK.
[^] # Re: faudrait forker l'article
Posté par Spyhawk . En réponse au journal C'est le jour pour s'informer (un peu) ... et en parler (beaucoup).. Évalué à 4.
Si tu utilises debian, tu utilises déjà la version Go-oo.
[^] # Re: à toi de voir
Posté par Spyhawk . En réponse au journal Vais-je résister à la tentation..... Évalué à 3.
[^] # Re: à toi de voir
Posté par Spyhawk . En réponse au journal Vais-je résister à la tentation..... Évalué à 10.
Entame de longues, pénibles, couteuses procédures judiciaires parce que le spammeur t'as spammé comme des millions d'autres. Ou fait justice. Tu te marreras bien et en plus, une occasion en or comme ça ne se présente pas tous les jours :)
PS: Ne lui donne pas la raison du pourquoi sa base de données s'est vidée, file nous le lien pour la suite plutôt. Les moules veulent jouer aussi :D
[^] # Re: Aie aie aie
Posté par Spyhawk . En réponse au journal Chrome, le futur navigateur de Google. Évalué à 1.
Y'a des risques qu'Opera passe à la trappe avec ce petit nouveau là.. (Opera ayant remplacé Firefox sur win depuis un petit moment déjà).
[^] # Re: Un bon point !
Posté par Spyhawk . En réponse au journal Chrome, le futur navigateur de Google. Évalué à 5.
Je ne comprends pas moi non plus pourquoi firefox la place si mal.. une relique du passée ?
[^] # Re: urpmi
Posté par Spyhawk . En réponse au journal Résolution de sudokus avec Aptitude. Évalué à 2.
Urpmi, Yum et autre Apt sont plus ou moins similaires : ils doivent gérer un compromis entre la rapidité de la résolution du problème de dépendances et la qualité de cette même solution.
Je me demande par contre comment se débrouillerait ZYpp sur les limites rencontrées par Apt dans la résolution des Sudoku, sachant qu'il utilise un solveur SAT qui est complet (il ne trouve pas une solution possible, mais il trouve la meilleure solution possible dans un temps très raisonnable.)
# Pour ceux qui voudraient en savoir plus..
Posté par Spyhawk . En réponse au journal Résolution de sudokus avec Aptitude. Évalué à 6.
D. Burrows, Modelling and Resolving Software Dependencies, June 2005 : http://people.debian.org/~dburrows/model.pdf
C'est assez long mais très instructif.
[^] # Re: gdmsetup
Posté par Spyhawk . En réponse au message interface choix de l'utilisateur au démarrage. Évalué à 3.
[^] # Re: Reflexion à voix haute
Posté par Spyhawk . En réponse au journal [Troll du vendredi] Mettre au même niveau la base des distributions stables en regard des logiciels utilisateurs est-il vraiment une bonne chose ?. Évalué à 2.
En ce qui concernent la création de paquets, les statistiques actuelles du dépôt central openSUSE donnent :
There are now 3716 projects, 48754 packages, 7204 repositories and 8606 confirmed users.
toutes achitectures (i586, x86_64, ia64) et toutes distributions confondues (mais surtout openSUSE).
Egalement, rien n'empêche n'importe qui (distribution, ou developpeur d'un projet quelconque) d'installer une copie locale sur sa ferme de compil/son ordinateur personnel, puique les sources du Build Service sont disponibles librement (mais on perd l'avantage de l'utilisation directe de la ferme de compilation du projet openSUSE).
Le but premier du Build Service, outre de creer des paquets pour plusieurs distrib facilement, est de dynamiser les interactions entre les projets (en recompilant automatiquement les paquets lors que c'est nécessaire), tout en ayant un lien direct avec les sources upstream.
Egalement, le BS peut s'utiliser de façon décentralisée, en "pointant" vers un Build Service central (celui d'openSUSE par défaut), les différents projets restant liés entre eux.
Les statistiques exactes sont donc difficiles à obtenir, et savoir "qui" l'utilise (et dans quel but?) est chose impossible. Mais aucune distribution majeure ne l'utilise à ma connaissance, chacune ayant son propre système local.
[^] # Re: Reflexion à voix haute
Posté par Spyhawk . En réponse au journal [Troll du vendredi] Mettre au même niveau la base des distributions stables en regard des logiciels utilisateurs est-il vraiment une bonne chose ?. Évalué à 9.
C'est pour l'heure assez peu utilisé en dehors d'openSUSE, et c'est bien dommage à mon avis.
http://en.opensuse.org/Build_Service
[^] # Re: ils ont deplacé le 1 avril au 1er septembre, dite moi que c'est ca
Posté par Spyhawk . En réponse au journal Bonus/malus écologique sur les ordinateurs : et Vista ?. Évalué à 3.
[^] # Re: ils ont deplacé le 1 avril au 1er septembre, dite moi que c'est ca
Posté par Spyhawk . En réponse au journal Bonus/malus écologique sur les ordinateurs : et Vista ?. Évalué à 3.
Quantité extractible pour pas chère <= Quantité de pétrole crée aucours des ages.
T'auras beau mettre autant d'argent et d'énergie dans l'extraction, quand il y en a plus ... il y en a plus.
Les commentaires précédents mettent surtout en valeurs que cette limite "ultime" n'a aucun sens : on ne l'atteindra jamais.
Si tu considères que chaque molécule d'hydrocarbure existante sur terre fait partie de cette réserve, alors oui, on peut presque dire que les réserves de pétroles sont... illimités, puisque les réserves sont exploitables aujourd'hui, demain ou alors.. jamais. Il y a, en absolu, du pétrole en abondance, et il y en aura toujours.
La notion de "réserves exploitables" est bien plus complexe que cela. Egalement, la disponibilité du pétrole "peu cher "est une toute autre histoire.
Sinon, oui, je connais la théorie du pic de Hubbert. Je sais aussi qu'il existe plusieurs autres facteurs dans la détermination des réserves exploitables. Voir par exemple : http://www.erdoel-vereinigung.ch/fr/oilfacts/Erdoelangebot/P(...) - oui, c'est un site de l'Union pétrolière suisse, mais il a le mérite d'être assez explicite et de ne pas avoir une approche trop "simpliste" sur ce sujet qui est très complexe.
Et sinon, j'ai vraiment fait une pique sur l'UE, hu ?
(note: je suis le premier à me méfier des données issues des compagnies pétrolières, j'ai fait mes études dans le domaine de l'environnement)
[^] # Re: ils ont deplacé le 1 avril au 1er septembre, dite moi que c'est ca
Posté par Spyhawk . En réponse au journal Bonus/malus écologique sur les ordinateurs : et Vista ?. Évalué à 3.
C'est pour ca que les sable bitumeux deviennent rentables à produire (alors qu'ils consomment une quantité importante d'énergie pour pouvoir les extraires, en plus de polluer la terre environnante).
C'est tout à fait cela, on parle ainsi de "réserves élastiques" Plus le pétrole est cher, plus il devient rentable d'exploiter du pétrole qui est moins facile d'accès, et plus il y a de pétrole disponible.
On arrive ainsi au "paradoxe des réserves", en toute contradiction avec l'offre de la loi et la demande.
Aussi, la "limite physique" n'est pas la quantité limitée de pétrole, mais plutôt l'énergie investie pour l'extraction. Lorsque qu'il faudra un baril d'énergie pour extraire un baril de pétrole, on arrêtera l'extraction, quel que soit le prix du pétrole sur le marché. Mais auparavant, les paramètres "d'optimisation des techiques d'extraction", "nouvelles techniques d'extraction" ou "d'exploitation de reserves alternatives" entrent en jeu.
[^] # Re: OpenSuse
Posté par Spyhawk . En réponse au journal SELinux. Évalué à 2.
[^] # Re: Everybody loves ATI !
Posté par Spyhawk . En réponse au journal L'état d'ATI sous linux. Évalué à 9.
- l'auteur du journal veut acheter une carte assez haut de gamme
- l'auteur du journal a besoin d'une accélération 3d fonctionnel (avec quelques fonctions récentes)
Au lieu de faire un sermon libriste (que tout le monde connait je pense), peut être est-ce que tu peux donner tes retours avec les drivers libres de chez ATI ?
- Les drivers libres donnent-ils des performances suffisantes par rapport aux besoins de l'auteur du journal ?
- Sinon, les specs déjà libérées (ou qui le seront prochainement) donneront-elles des drivers 3D fonctionnels, par rapport aux besoins de l'auteur du journal, à court terme (quelques mois) ?
Je ne pense pas, mais tes réponses m'intéressent grandement. Si je me trompe je serais heureux de l'apprendre :)
# nVidia
Posté par Spyhawk . En réponse au journal L'état d'ATI sous linux. Évalué à 7.
Historiquement, j'ai toujours conseillé nVidia, parce que "ça marchait mieux" avec les drivers closed-source. Aussi, comme tu le cites, ATI a fait pas mal de progrès dernièrement, et rattrapé une partie de son retard. Mais selon un article en anglais paru récemment en journal de seconde page (et dont je ne retrouve plus le lien :/ si l'auteur du journal passe par ici..), nVidia propose toujours la meilleure implémentation d'openGL.
Jusqu'à il y a quelques jours, je t'aurais dis "Je ne sais pas", parce que les derniers drivers nVidia ont eu pas mal de soucis avec KDE 4 notamment, pendant une assez longue période. Cependant, selon les tous derniers drivers 177.68 Beta du 21 août :
Improved GPU video memory management coordination between the
NVIDIA X driver and OpenGL implementation; this should
improve performance with e.g. the KDE4 OpenGL compositing
manager.
http://www.nvnews.net/vbulletin/showthread.php?t=118244
Et, après test effectué, je dois dire que c'est le jour et la nuit par rapport aux versions précédentes.
Alors pour moi, dans le cadre actuel et pour des drivers 3D performants, c'est logiquement nVidia.
[^] # Re: dubitatif
Posté par Spyhawk . En réponse au journal petit bug chez google (gmail). Évalué à 10.
GMail offre un service payant aux entreprises (j'ai une adresse qui utilise ça).
Grosso modo, c'est GMail, mais avec le logo de l'entreprise, pas de pub, et pas de GTalk non plus.
Donc oui, c'est intéressant pour une PME : service mail à moindre coût. Reste le problème de la confidentialité (y a-t'il une clause dans le contrat à ce sujet?) et des bugs... un peu plus qu'ennuyeux.