Cette nouveauté, est-il indiqué, a lieu dans un contexte où gnu/linux prend une plus grande importance y compris dans le domaine du jeu vidéo (version UT2003 64bits sur AMD Athlon 64 avec un linux en 64 bits - pardon auprès des fidèles du 32 bits - il y a quelques jours). N'oublions pas la sortie prochaine du nouveau nVidia GeForce FX qui semble très prometteur.
NdM: nouveauté importante : le support du S3TC qui permet de jouer à ut2k3.
![[en]](../images/en.png)
the Inquirer (1960 hits)![[fr]](../images/fr.png)
ATI (4883 hits)
> Lire la dépêche (115 commentaires, moyenne: 1,6).
Vous avez demandé le commentaire #151620.
Run by 
Cette page a été générée par Templeet en 0.1476s (dont 0.0142 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Superbe merde
Non seulement ces drivers ne sont fournis qu'en binaires, mais en plus, ils ne sont fournis qu'en RPM. Merci ATI.
[^]Re: Superbe merde
ARGLLLLL je suis en train de preparer les caracteristiques du futur pc sur lequel je vais travailler et j'ai failli demander une carte ATI suite a l'annonce de l'arrive de drivers correctes mais le probleme c'est que j'utilise Debian... Donc la je me repose la question dois je prendre un ATI... et sinon quel marque prendre. Nvidia il y a pas la 3d avec les drivers nv (de xfree) puis il y a des problemes avec wmaker si j'ai bien suivi et les drivers fourni par nvidia ont des fuites de memoires ce qui est tres genant tout de meme particulierement si la machine n'est pas prevu pour etre reboote tous les jours... Que peux t'on prendre comme bonne carte graphique du coup?
[^]Re: Superbe merde
Les drivers fonctionnent sur une debian, faut juste extraire les fichiers, les installer au bon endroit à la mimine, et ensuite faut bricoler un peu pour compiler leur driver noyau (en gros, ca compile pas avec gcc 2.95, j'ai mis une tarball avec les sources modifiées pour que ca compile sur http://cfergeau.free.fr/ati_kernel_driver_source.tar.bz2(...) )
Au niveau des perfs, ut2003 avait l'air super lent comparé à la version windows, mais y avait peut etre des pb de reglage de mon coté
[^]Re: Superbe merde
Les drivers 2d libres existent pour les 9700 et 9500, pour les 8500 et 9000, c'est 2d et 3d, faut juste prendre le cvs de xfree
[^]Re: Superbe merde
compiler cvs de xfree t'es rigolo, autant sur ma machine perso je suis pres a teste des trucs (quoique la compil a la mano et sans pouvoir packager de xfree ca je le ferai pas) autant sur la machine boulot c'est pas le cas et j'utilise les binaires officiels.
[^]Re: Superbe merde
Tu demandes s'il y a des drivers corrects, je te répond. C'est pas de ma faute si tu es limité par ta distro. pour info, xfree 4.3 devrait sortir fin janvier
[^]Re: Superbe merde
AUCUNE distribution n'a le cvs xfree par defaut, heureusement. Le pc je commence a m'en servir debut janvier donc ca le fait pas. xfree 4.3 fin janvier donc pour les tests debian qui est la distribution permettant les archis autres que pc ca veut dire pas tout de suite...
[^]Re: Superbe merde
tu peux aussi compilé le cvs du dri.. t'aura des drivers pour tes radeons
[^]Re: Superbe merde
La seul carte aved des drivers 3d potables libres, c'est l'ati 7500 (bba). Vu la différence de perf et de prix avec les autres cartes. Il va couler de l'eau sous les ponts avant que les autres cartes deviennent intérescantes.
[^]Re: Superbe merde
J'ai entendu dire que les drivers dri cvs pour la 8500 était pas mal du tout.. Quelqu'un aurait plus d'infos à ce sujet ?
[^]Re: Superbe merde
oui ils marchent... j'ai quand meme des problemes (mais qui aparement ne sont pas super rependus): pas de switch en console sinon freeze (genant pour faire un halt)... mais parfois ca freeze pas, je vois pas d'ou ca vient.
Niveau perfs c'est pas mauvais (j'ai testé avec q3)... Sur rtcw les couleurs etaient niquées lors de mon dernier test qui remonte a un petit mois. Tribes2 a encore des problemes, j'ai encore testé....
[^]Re: Superbe merde
g u ce genre de probleme avec les drivers nvidia, c t un conflit avec le driver framebuffer (d'où le switch en console), essaye donc vesa ou kkchose du genre pour le framebuffer.
[^]Re: Superbe merde
pas de framebuffer ici =)
[^]NVidia + console
Les problemes avec les cartes NVidia sont dus aux conflits entre le FrameBuffer NVidia et le driver nvidia pour XFree 4.x (fourni par NVidia). Il suffit de desactiver le FrameBuffer NVidia et de n'utiliser que le FrameBuffer VESA pour ne plus avoir aucun probleme de switch en console.
Je ne sais pas si les drivers ATi sont soumis au meme genre de problemes, mais ca ne m'etonnerait pas outre mesure...
[^]Re: Superbe merde
Salut,
Il existe des packages debian de DRI basé sur leur CVS:
http://dri.sourceforge.net/snapshots/README.Debian(...)
<<<
Debian packages (currently for powerpc and i386) based on CVS snapshots are available via
deb http://people.debian.org/~daenzer/dri-trunk/(...) ./
Install the xserver-xfree86-dri-trunk package and build the DRM from the
drm-trunk-module-src package (most conveniently using kernel-package).
Feedback about the packaging goes to Michel Dänzer <daenzer@debian.org>,
feedback about the drivers to dri-devel@lists.sf.net .
[...]
>>>
Personelement, j'ai une radeon 8500, je compile moi même le tout, ca me permet de plus facilement débugger. Cela dit, actuellement, ca marche plutot bien, malheureusement, les performances sont inférieurs a celles des drivers ATI, mais ceux d'ATI ont d'autres problèmes (pas open-source, Xv buggé, certaines résolutions ne passent pas, et j'en passe).
[^]Re: Superbe merde
J'ai essayer l'install de gatos mais je n'ai réussi qu'à complètement planté X.
[^]Re: Superbe merde
d'apres ce que je sais gatos ne marchera pas avec les 8500 &cie pour ce qui est 3d (ils ont pas encore integré ce qui vient du dri j'imagine)
[^]Memory leak
Sur http://www.minion.de/nvidia.html(...)
il y a des patch pour la partie noyau des drivers nvidia pour linux.
Il permettent de les faire fonctionner sur un noyau 2.5 (et 2.4) et ils corrrigent aussi quelques bugs de stabilité ;)
Perso j'ai pas (encore?) testé, mais bon le gars qui fait ces patchs a travaillé chez nvidia pour créer le driver donc...
Toujours est-il que si le driver était ouvert, la communauté pourrait corriger plus vite ce genre de bug :p
[^]Re: Memory leak
D'ailleurs ces patchs sont utilisés par la Gentoo (cf. /usr/portage/media-video/nvidia-kernel/ChangeLog) : "Add page_alloc and linux-2.5 kernel patches."
J'utilise quotidiennement le driver 1.0.3123 avec un chipset ALI M1671 et une GeForce 2 Go sans problème.
"Join the Navy; sail to far-off exotic lands, meet exciting interesting people, and kill them."
[^]Re: Memory leak
Juste en passant, tu peux utiliser APM avec ? Parce que c'est quand même un sacré problème sur un portable, tu ne trouves pas ?
[^]Re: Superbe merde
Je ne reboote ma machine perso que pour changer de version de noyau ou de driver NVidia. Je n'ai jamais eu de problèmes de fuites mémoire avec leur driver, ce qui ne veut pas dire qu'il n'y en a pas, ça doit dépendre de la config (Athlon XP 2400 + GeForce 4 Ti 4200 + SiS 745 dans mon cas).
Un conseil par contre pour ta future machine, si tu choisis un Athlon, évite les chipsets VIA (ou pire, NVidia nForce !) et choisis un SiS. Tout le monde n'a pas d'ennuis avec mais certains south bridges VIA sont des merdes d'un fort beau calibre.
[^]Re: Superbe merde
meme avec des intel les chipset VIA c'est de la merde, probleme de ports usb etc..
[^]A propos du nForce
Les derniers drivers sont là : http://www.nvidia.com/view.asp?IO=linux_nforce_1.0-0248(...)
bon ce que j'en dis moi...
[^]Re: Superbe merde
Quand je pense qu'il y en a encore pour ne pas avoir une Matrox ...
C'est peut etre le fait d'avoir des drivers ouverts et complets, un support du constructeur, une exploitation maximale de toutes les fonctionnalités par du ligiciel libre et une qualité d'affichage excellente qui poussent certains à acheter autrechose ?
[^]Re: Superbe merde
Ou tout simplement les maigre performances 3D comparées aux ATI et NVidia.
[^]Re: Superbe merde
J'avais cru comprendre qu'il n'y avait pas de drivers 3d pour la parkhelia et qu'aucune carte Matrox n'etait en mesure de faire tourner ut2003.
C'est peut etre pour ça qu'il y en a encore pour ne pas avoir de Matrox?
[^]Re: Superbe merde
Tant pis pour la Parhelia, une Millenium, Mystique ou carrément une luxueuse G200 voir une G400 feront tout à fait l'affaire.
Mais j'oubliais que pour la plupart des possesseurs de PC, ce n'est qu'une super console de jeu ...
[^]Re: Superbe merde
quand on parle dans une news de drivers qui permettent des perfs 3d interessantes, on va pas comparé a un dino... Faut comparé avec ce qu'il faut.
[^]Re: Superbe merde
Le prix ?
[^]Re: Superbe merde
pas du tout efface , matrox a changé sa politique pour le parhelia , seul la partie 2d est opensource .
je te conseille de lire ca :
http://www.linuxgames.com/news/feedback.php?identiferID=5911(...)
[^]Re: Superbe merde
Je parlais plutot de bonnes vieilles Mystique/Millenium en PCI ou de G200/G400 en AGP, ca c'est de la carte graphique, et en plus elles ne coutent plus rien ou presque.
C'est vrai que pour le prix d'une Parhelia, il vaut mieux s'offrir une carte à base d'ATI ou de NVIDIA si on a un "PC de jeu" (et rien n'empeche pour quelques clous en plus de s'offrire une Mystique pour travailler).
[^]Re: Superbe merde
Les anciennes cartes Mystiques/Millenium PCI posent malheursement des problèmes avec XFree 4 (gel complet de la machine). Et comme ces cartes ne sont pas très récentes, la correction n'est pas une priorité :-(
[^]Re: Superbe merde
hummm, j'ai une Millenium II et une G200 PCI dans ma machine et je n'ai jamais eu de freeze. Pareil chez un ami qui a une mystique et une Millenium I.
Pour les version AGP (G200/400 ...), c'est vrai, il y avait des freeze en 3D, mais t'est un peu dur, le CVS d'XFree contiend les corrections (ok, il faut attendre le 4.3, mais c'est pareil pour tout le monde)...
[+] [^]Re: Superbe merde
Les drivers d'ATI ne sont fournis qu'en binaire, mais ils fournissent une partie des specs pour que les developpeurs puissent faire des driver libre.
Une partie seulement pour des problemes Macrovision par exemple.
Mais il y a quand meme la majorite des specs, le probleme c'est juste que c'est extremement complique de faire un driver pour ces usines a gaz que sont l
Pour ce qui est du format RPM, c'est le format de la LSB, si ta distribution ne supporte pas ce format, utilise les outils de convertion qui vienne avec ta distribution: avoir different format de packaging, c'est aussi stupide que si les formats de prises electrique n'etait pas standardise, si tu veux utiliser quelque-chose d'autre que le standard, il faut utiliser des adaptateurs!
[^]Re: Superbe merde
Ça veut rien dire ça. C'est pas parce que la LSB a choisi le format rpm qu'il faut ne donner que des rpm. D'abord la LSB n'aurait jamais dû s'intéresser au format de package. Ensuite, pourquoi faire des rpm, c'est moins répandu que les installshied/... (sous windows). Enfin, la plupart des gens ont pas trop envie que rpm aille foutre la merde dans leur fs (en particulier dans /etc).
[+] [^]Re: Superbe merde
> D'abord la LSB n'aurait jamais dû s'intéresser au format de package.
Ca c'est ton avis, pas le mien: les formats de packages, c'est comme les formats de prises électrique, si tu en as plusieurs c'est le bordel pour installer tous ensemble.
Le but ce n'est pas d'avoir le format le mieux, franchement les .deb et .rpm sont grosso-modo équivalent, le but c'est d'avoir des OS qui sont le plus facilement administrable.
Je ne connais pas le format installshield, mais s'il était ouvert (tous le monde peut packager leur projet sans avoir a payer une license au fabriquant d'installshield), multi-plateforme (c'est un standard de Windows, je ne sais pas s'il dépend de spécifité de Windows), puissant et avec des outils libre, oui cela aurait été une bonne idée de l'utiliser: comme cela les projets multi-plateformes n'aurait eu qu'un seul outil de packaging a utiliser..
> Enfin, la plupart des gens ont pas trop envie que rpm aille foutre la merde dans leur fs (en particulier dans /etc).
Je ne sais pas d'ou tu sors cela, mais "la plupart des gens" utilise justement des distributions pour se simplifier la vie, et il est plus rapide de taper urpmi <toto> et que lire le README, le INSTALL, du package, de ses dépendances,compiler, etc..
Pour ce qui est de mettre la merde dans le /etc, les bons outils de packaging te permettent de faire une install a blanc pour te dire quelle fichiers ils vont modifier ou alors de rediriger le / dans /tmp/toto et apres tu regarde ce qu'il a fait dans /tmp/toto.
Et si un rpm peut te mettre le bazar dans /etc, un make install peut faire la même chose!
[^]Re: Superbe merde
c'est comme les formats de prises électrique, si tu en as plusieurs c'est le bordel pour installer tous ensemble
Faut être tordu pour 'installer des prises US en France et vice versa, ou alors savoir exactement ce que l'on fait.
franchement les .deb et .rpm sont grosso-modo équivalent
C'est ce qu'essayent de faire croire red hat et mandrake. Suffit de comparer les page de man des differents systèmes pour s'appercevoir que le rpm et ses outils associés sont derrière le système debian. Enfin bon, ca va troller (sans moi) cherie.
le but c'est d'avoir des OS qui sont le plus facilement administrable
Avec une techno de 1997 ?
[installshield si... et si... et si...] cela aurait été une bonne idée de l'utiliser
Quand bien même il repondrait à toutes ces conditions... Ligne de commande vs GUI... troll interminable en perspective.
: comme cela les projets multi-plateformes n'aurait eu qu'un seul outil de packaging a utiliser
Bein non... mois je prefère la ligne de commande pour les fonctions install / update / desinstall / reinstall / reconfigure / upgrade / downgrade(si !)
il est plus rapide de taper urpmi toto
oui, un peu plus qu' apt-get install toto....
Tu as des actions mandrake ? :o)
Puisqu'on parle de la LSB, je ne crois pas qu'il faille s'arreter au format des package, d'ailleurs la section en question est toute petite:
http://www.linuxbase.org/spec/refspecs/LSB_1.2.0/gLSB/swinstall.htm(...)
On y apprend que ca s'appuie sur une versions des rpm de 1997. Avec "quelques" limitations:
- Packages may not use RPM triggers
- Packages may not depend on the order in which scripts are executed (pre-install, pre-uninstall, &c), when doing an upgrade
- Some versions of RPM may produce packages which contain extensions or modifications to the RPM package format beyond what has been documented in the appendix of the Maximum RPM book. An LSB-conformant package must not contain any of these extensions
- The distribution itself may use a different packaging format for its own packages, and of course it may use any available mechanism for installing the LSB-conformant packages
Enfin bon, la section package dit juste qu'une distrib "LSB" ne doit pas forcemment avoir un format rpm, en revanche, elle doit avoir un mecanisme pour installer des packages "LSB" (rpm de 1997 sans fioriture)
Il y a des trucs beaucoup plus interessant dans la LSB ( http://people.debian.org/~joeyh/lsbtest/current/(...) ), et je rejoins le post auquel tu reponds, en disant qu'ils aurraient du s'abstenir de s'interesser au format de package. Pourquoi:
- Ils ont tiré leur standard vers le bas en prenant le plus petit denominateur commun (du coup, en excluant le .deb)
- Quelqu'un qui a aujoud'hui le choix d'installer le package de sa distrib ou un rpm de 97 "LSB copain", je pense qu'il va prendre le package de sa distrib quel que soit son format de package.
- Pour un editeur, il ne devrait ne pas s'occuper des histoires de dépendances/conflit _avec des packages_. c'est le role du packageur, qui lui, connait sa/ses distribs. Ce qui interesse l'éditeur, c'est que les differentes distribs, interagissent de la même façon avec son soft.
On ne peut pas dire qu'il y a foule sur http://www.lanana.org/(...) ( http://www.linuxbase.org/spec/refspecs/LSB_1.2.0/gLSB/pkgnameconv.h(...) )
Cela dit, la resolution de conflit avec nombre de passe fixé, franchement, C'est pas propre. Je garde mes .deb. Et toc !
[+] [^]Re: Superbe merde
> Faut être tordu pour 'installer des prises US en France et vice versa, ou alors savoir exactement ce que l'on fait.
Bon exemple des problemes posés: pas mal d'alimentations fonctionne sur les 2 normes: ca ne m'étonnerait pas qu'elles soient plus cher a cause de cela: juste un peu plus cher certes vu les volumes en question mais plus cher tout de meme.
Pareil pour les logiciels libres: en général on ne paye pas pour eux, mais le temps passer a générer n packaging pourrait etre mieux utilisé a paufiner un seul packaging.
>>le but c'est d'avoir des OS qui sont le plus facilement administrable
>Avec une techno de 1997 ?
? La techno Unix est super-vieille, l'age d'une techno n'est pas le premier critere autrement il faut abandonner Unix pour Windows.
> - Ils ont tiré leur standard vers le bas en prenant le plus petit denominateur commun (du coup, en excluant le .deb)
D'accord: ils auraient prendre un format RPM entier et recent, pas juste une portion: comme cela il y aurait toutes les fonctionnalités de RPM, pas juste une partie. Les distros auraient mis a jour leur version pour etre conforme.
Pour ce qui est d'autoriser le format .deb: imagines un peu si les organismes de normalisations avaient autorisés plusieurs tailles de prise pour la maison, le bordel..
Pour moi, rien n'empeche de faire l'equivalent de apt-get avec des .rpm, mais toute comparaison des formats .rpm et .deb degenere en flamewar et tourne en général a: "avec mon format X on peut faire cela avec le format Y on ne peut pas, avec une réponse aussitot: tu retardes, cela fait tant d'années que le format Y supporte cela."
> 'installer le package de sa distrib ou un rpm de 97 "LSB copain
Malheureusement les RPM "tout chaud" sortis par les distros sont souvent buggés, avec une distribution conforme a LSB, je crois que j'hésiterais avec un RPM fait par le gars qui code le logiciel.
> Cela dit, la resolution de conflit avec nombre de passe fixé, franchement, C'est pas propre. Je garde mes .deb. Et toc !
Tu as tout le fait le droit, mais par contre ne t'étonnes pas de devoir utiliser de plus en plus l'outil de convertion .RPM --> .DEB.
[+] [^]Re: Superbe merde
"Pareil pour les logiciels libres [...] le temps passer a générer n packaging pourrait etre mieux utilisé a paufiner un seul packaging"
mouaip... Le temps passé à supporter sur n archi, pourrait etre mieux utilisé à...
Le temps passeé à supporter n OS, pourrait etre mieux utilisé à...
Le temps passé à traduire pourrait etre mieux utiliser à enseigner l'anglais...
il tient pas ton raisonnement. Beaucoup de gens ont des visions differentes sur ce que devraient être un proc, un os, une distrib, et font, la plupart du temps, des boulots differents.
"La techno Unix est super-vieille, l'age d'une techno n'est pas le premier critere "
Bon je la refais... Avec les rpm de 97 ? mouarg...
D'accord: ils auraient prendre un format RPM entier et recent...
Ah ? et pourquoi pas un .deb éprouvé, qui fonctionne et possède plus de fonctionnalités ? Par ce que fédérer aurrait été bien plus difficile ? sans doute. Je me demande pourquoi Mandrake a "choisi" le rpm pour leur distrib. Competence interne ? Partenariat ?
Pour la normalisation, tu ne reponds pas au problème. La LSB aurait mieux fait de s'abstenir en ce qui concerne les packages. L'editeur, il s'en tape, c'est pas son boulot et il y a des gens beaucoup plus competent que lui pour le packaging. L'utilisateur, il s'en tape aussi, parceque les packages lui sont fournis par sa distrib.
toute comparaison des formats .rpm et .deb degenere en flamewar
plus facile que de lire les pages de man sans doute.
les RPM "tout chaud" sortis par les distros sont souvent buggés
Sans blague ? :o)
je crois que j'hésiterais avec un RPM fait par le gars qui code le logiciel
Là tu te mets le doigt dans l'oeil. Le gars qui code le logiciel il s'en tape. L'editeur ? aussi. Pourquoi ? Parcequ'il y a des gens qui vont faire ça gratos pour lui, et mieux que lui.
ne t'étonnes pas de devoir utiliser de plus en plus l'outil de convertion .RPM --> .DEB
N fois 0 (zero). Super. J'ai dejà le temps d'en voir arriver des lsb-trucs.rpm dont j'ai besoin et qui n'ont pas d'equivalent dans ma distrib.
Pas de nvidia chose ou d'ati machin sur mes machines. Ils peuvent bien sortir un lsb-truc, ca me ferait ni chaud, ni froid: j'achete pas leur materiel, et je ne le recommande pas, bien au contraire.
[^]Re: Superbe merde
>Ah ? et pourquoi pas un .deb éprouvé, qui fonctionne et possède plus de >fonctionnalités ? Par ce que fédérer aurrait été bien plus difficile ? sans doute.
ou peut etre parce que les grosses boites qui ont de l'influence (redhat, suse, mandrake) ont pousse plus fort que debian ?
>Je me demande pourquoi Mandrake a "choisi" le rpm pour leur distrib. >Competence interne ? Partenariat ?
euh la raison est tres simple: mandrake est nee a partir d'une redhat (vers la 5) en recompilant tout les packages pour processeurs pentium, en se disant que comme ca la distro sera super plus vachement mieux rapide que les autres, probleme ils bidouillaient aussi les packages et a la fin ca plantait tout les 4 matin. Remarque j'ai aide un pote a installe la 9 la semaine derniere et l'installateur graphique a refuse de libere le lecteur cdrom au momment de changer de CD parce qu'il n'avait pas pige qu'il y avait 2 lecteurs dans la machine, il en debloquait donc un mais pas le bon, bravo mandrake (et les urpmi de la 8.1 font exactement la meme chose ...)
>Pas de nvidia chose ou d'ati machin sur mes machines. Ils peuvent bien sortir un >lsb-truc, ca me ferait ni chaud, ni froid: j'achete pas leur materiel, et je ne le >recommande pas, bien au contraire.
sniff j'ai abandonne ma G400 Max l'annee derniere a cause de conflits avec la carte mere (chipset K7V) qui generaient des plantages sous win.... j'aurais jamais du ... et j'aurais jamais du achete une geforce2 ... bon et maintenant ATI qui se met a faire des drivers binaires :(
enfin vivement la nouvelle licence du kernel qui refusera les drivers binaires (normalement pour le prochain noyau stable).
Il [e2fsck] a bien démarré, mais il m'a rendu la main aussitot en me disant "houlala, c'est pas beau à voir votre truc, je préfèrerai que vous teniez vous même la tronçonneuse" (traduction libre)
[^]Re: Superbe merde
Hors-sujet: urpmi a des problemes:
Pour le probleme de cdrom, je confirme que urpmi gere tres mal la chose: en general pour installer une distrib j'utilise des CD-RW (evolue trop vite pour gacher des CD-R) or j''ai aussi un vieux lecteur de CD dans mon ordinateur, pour une raison que j'ignore urpmi va toujours chercher les package sur le lecteur de CD par le graveir : d'ou a chaque upgrade, destruction de la base, reconstruction.
C'est pénible, c'est long et cela m'est arrivé d'avoir du mal a reconstruire la base, j'ai essayé de regarder les sources,
--> beurk! du Perl, sauce imbitable. Fin HS.
Tu achetes une GeForce et attends vivement que le kernel n'autorise plus l'import de driver closed-source?
C'est du masochisme?
ATI fournit peut-etre un driver closed-source, mais eux ils fournissent les specs de la carte (pas toute malheureusement) et il y a des projets open-source qui essaye de faire des driver.
Ce serait encore s'ils fournissaient leur driver en open-source, mais c'est toujours mieux que NVidia qui lui ne fournit pas du tout les specs de sa carte..
Juste pour m'oter un doute: ATI fournissait ses specs jusqu'a la Radeon 8500, mais est-ce toujours vrai pour la 9700Pro (R300)?
[^]Re: Superbe merde
urpmi : a mon avis il doit y avoir un mix au niveau de ton /dev/cdrom. J'ai un graveurs et un lecteurs dvd, je n'ai aucun problème. J'ai même recopier tous les RPM dans un repertorie de root, comme ça plus besoin de CD !
[^]Re: Superbe merde
Bonjour la cohérence!
Tu te plain de ce que rpm pourrais faire sur ton fs, alors que tu peux désactiver les script et regarder tous les fichiers inclus avant d'installer.
Mais par contre tu parle d'installshield qui produit des programmes d'installation fermés où il est impossible de savoir à lavance ce qu'il vont fair comme saloperie à ton système.
[^]Re: Superbe merde
Les deux arguments sont déconnectés et ne concernent pas le même point de vue. Je connais rien à installshield. Tout ce que j'ai retenu, c'est qu'il y en avait souvent sous windows.
Le problème c'est que si on dit : il faut utiliser le format de package le plus répandu pour que les éditeurs n'aient pas à se fatiguer, alors pourquoi pas : ilfaut utiliser le système d'exploitation (enfin le truc, quoi) le plus courant pour pas que les éditeurs aient à se fatiguer. En plus, ils connaissent déjà très bien.
>où il est impossible de savoir à lavance ce qu'il vont fair comme saloperie à >ton système.
C'est pour ça qu'il faut mieux faire des packages tgz. Ceux là, ils ne font jamais de mal, il suffit de choisir où tu les mets (répertoire perso puis direct /usr/local ou effacer).
[^]Re: Superbe merde
Enfin, la plupart des gens ont pas trop envie que rpm aille foutre la merde dans leur fs (en particulier dans /etc).
Tu préfères que les fichiers de config et les exécutables soient dispersés aux quatre vents, au bon vouloir du gars qui a fait le package ? Bonjour la maintenance...
[^]Re: Superbe merde
Propos ironiques mal commpris, je reprends.
C'est pour ça que je pense qu'il vaut mieux des tgz bimaires. Tout le monde est d'accord, ça s'extrait ça ne s'installe pas, ça va rien mettre nulle part sauf si tu le veux par défaut. T'as besoin de rien installer de particulier (qqun n'a pas tar et gz d'installés?).
Aussi bien que tu fasses les programmes de conversion ou d'installation, je ne pense pas que tu puisse te débrouiller pour faire un système ou tu ferais cohabiter deux gestions des packages qui tienne la route.
[^]Re: Superbe merde
Enfin, la plupart des gens ont pas trop envie que rpm aille foutre la merde dans leur fs (en particulier dans /etc).
rpm ne fout pas la merde dans /etc, puisqu'il fait des fichiers .rpmnew :
> ls /etc/*.rpmnew
/etc/inittab.rpmnew /etc/sysctl.conf.rpmnew
Et il te fait un petit avertissement du genre (si je me souviens bien) warning : toto created as toto.rpmnew lors de l'installation du package.