Cette version reprend basiquement toutes les fonctionnalités de la version pour Pentium et compatibles.
Aller plus loin
- Le communiqué de presse (1 clic)
- Les caractéristiques du produit (2 clics)
- Article précédent (0 clic)
Mandrakelinux 10.0 pour AMD64 est dispo.
5
mai
2004
Après plusieurs versions "Beta", la version finale Mandrakelinux 10.0 Official pour AMD64 est disponible en pré-commande chez Mandrakesoft sous forme d'un jeu de 4 CDs.
Cette version reprend basiquement toutes les fonctionnalités de la version pour Pentium et compatibles.
Cette version reprend basiquement toutes les fonctionnalités de la version pour Pentium et compatibles.
# Mdk sur AMD64
Posté par fab . Évalué à 2.
Sinon c cool pour mdk ça élargi la part de marché puis si on veut se faire un cadeau on sait qu'on pourra tourner sous linux avec. ( Si mes souvenirs sont bon Debian et Gentoo supporte les processeurs 64 ) .
[^] # Re: Mdk sur AMD64
Posté par chx dein . Évalué à 6.
Forum amd64 : http://forums.gentoo.org/viewforum.php?f=46(...)
Liste des ebuilds amd64 : http://packages.gentoo.org/archs/amd64/(...)
Documentation pour l'installation sur amd64 : http://www.gentoo.org/doc/fr/handbook/handbook-amd64.xml?full=1(...)
Voila.
Sinon, pouvez-vous me dire ce qu'apporte le amd64 pour une utilisation intensive ? Est-ce mieux qu'un pentium 4 si on utilise peu les jeux, et si on aime avoir beaucoup d'application utilisées en même temps ?
[^] # Re: Mdk sur AMD64
Posté par 007 . Évalué à 2.
FC1 :
http://www.redhat.com/archives/fedora-announce-list/2004-March/msg0(...)
La FC2 pour amd64 devrait sortir en même temps que la FC2 pour i386. Le 17 mai normalement. Pour les impatients, la FC2 test 3 est sortie il y a quelque jours pour i386 et amd64 :
http://www.redhat.com/archives/fedora-announce-list/2004-April/msg0(...)
Elle sera gratos.
[^] # Re: Mdk sur AMD64
Posté par 007 . Évalué à 1.
Ça apporte rien. L'intérêt du 64 bits c'est l'espace d'adressage mémoire qui est plus grand (très intéressant pour les serveurs).
> et si on aime avoir beaucoup d'application utilisées en même temps ?
Si tu n'as pas besoin d'un PC avec plus de 4 Go de ram c'est pas intéressant.
[^] # Re: Mdk sur AMD64
Posté par reno . Évalué à 6.
> Ça apporte rien. L'intérêt du 64 bits c'est l'espace d'adressage mémoire qui est plus grand
Tu exagère un peu, l'amd64 n'apporte pas que le 64 bits, mais aussi 16 registres au lieu de 8, ce qui peut amméliorer les perf: le compilateur voit plus de registres: il peut mieux les utiliser.
Alors pour les perf, ça depend bien sûr du code, ça peut aller de 0 à 20%.
Il y a aussi un mode pour rendre les pages executables non-inscriptible ce qui complique la vie pour les pirates voulant exploiter les buffer overflow.
[^] # Re: Mdk sur AMD64
Posté par 007 . Évalué à 1.
Je crois que c'est possible :-)
J'ai un PC d'un an d'age et pas envis de le changer. En général je suis peu les news hardware tant que j'ai pas l'intention d'acheter du matos.
Ce qui était vrai hier sera faut demain.
Putain l'informatique ça va trop vite.
[^] # Re: Mdk sur AMD64
Posté par Pascal Havé . Évalué à 5.
Par ailleurs, les performances SMP sont remarquables du fait que, contrairement au PIV & co où il n'y a qu'une seule mémoire centrale, l'Opteron dispose d'une architecture un peu plus NUMA où chaque proc dispose d'abord d'une mémoire propre, mais qu'il peut partager avec ses collègues.
[^] # Re: Mdk sur AMD64
Posté par yxorp . Évalué à 1.
De même, le code devrait certainement être partiellement réécrit, du moins pour profiter de certaines optimisations rendues possibles par un nouveau processeur, ou pour ne plus avoir à se soucier de certaines limitations des architectures pour lesquelles il était prévu.
Même le meilleur processeur n'est rien si il n'existe pas de compilateurs un tant soit peu corrects pour l'utiliser.
[^] # Re: Mdk sur AMD64
Posté par atlexx . Évalué à 2.
l'adressage n'a pas attendu les processeurs 64bits pour s'étendre au dela de 32 bits (souvent pour les serveurs) ou se raccourcir (processeurs pour pda).
par exemple, le motorola 68000 etait un 16 bits a adressage sur 32 bits si je me souviens bien. je n'ai pas d'exemple plus récents car je ne m'interresse pas plus que cela au sujet donc mes infos ne sont plus très fraiches...
il me semble que la designation de 64 bits se referre surtout à la taille nombres manipulés dans des registres de calcul ...
La manipulation des Nombres sur 64 bits apporte des gains importants sur certains types de calculs pour lesquels il était nécessaire de traiter les données en plusieurs passes.
cela concerne par exemple les algorithme de compression, les manipulation d'objets graphiques / 3D , de son etc ... ces lacunes etaient jusqu'a présent paliées par l'utilisation de "verrues" (je sais que le terme est un peu excessif car l'apport de ces extensions va au delà) type MMX SSE 3DNow etc...
je laisse la suite aux specialistes car la description a été faite plusieurs fois dans ces forums, souvent a propos de l'amd64 ou de l'itanium.
[^] # Vieux procs
Posté par Arthur Accroc . Évalué à 2.
Non, c'était un processeur 32 bits à bus mémoire 16 bits, tout comme l'Intel 8088 était un processeur 16 bits à bus 8 bits, pour des raisons de coût d'architecture.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Vieux procs
Posté par Patrice Mandin . Évalué à 2.
En réalité, c'est un peu plus vicieux. En interne (pour le programmeur), tout est en 32 bits (registres, adressage, calcul). En externe (au niveau des pattes de la puce), on a 24 bits d'adressage (16 Mo addressables), et 16 bits de données (transfert d'un mot à la fois).
La génération 68020 a apporté le full 32 bits.
Le 68030 a intégré la MMU (mais Atari pour le Falcon avait gardé le brochage du 68000 du ST: 24 bits addressables et 16 bits pour les données. Ca la fout mal pour un processeur aussi performant).
Le 68040 a intégré le FPU.
Le 68060 a intégré 2 68040 (c'est bien ça ?).
Petite pub (pour une carte accélératrice pour Falcon, à base de 060):
http://www.czuba-tech.com/CT60/french/present.htm(...)
(Note: il doit en rester une dizaine de disponibles, à l'heure actuelle, pour les intéressés). C'est vrai que ça fait jamais que 7 ans de retard sur les Amiga.
[^] # Re: Mdk sur AMD64
Posté par dguihal . Évalué à 1.
[^] # Re: Mdk sur AMD64
Posté par Christophe BAEGERT . Évalué à 0.
A mon avis ca vient du controleur mémoire intégré.
[^] # Re: Mdk sur AMD64
Posté par Misc (site web personnel) . Évalué à 3.
En effet, une appli 32 bits a besoin de libs 32 bits, comme la glibc. Donc, un fichier /usr/lib/libmachin.so
Si une appli 64 bits a besoin de la même lib, il faut une version /usr/lib/libmachin.so en 64 bits. Comme il y a un conflit de noms de fichiers, ça ne marche pas.
C'est pour ça que mdk depuis 2 ans travaille sur ça, en placant les libs 64 bits dans lib64.
[^] # Re: Mdk sur AMD64
Posté par 007 . Évalué à 0.
Pour Fedora c'est fait.
FC1 : http://fr2.rpmfind.net/linux/fedora/core/1/x86_64/os/Fedora/RPMS/(...)
Cherche les paquets i386.rpm.
En réalité c'est fait depuis la RH 9 (rpm-4.2.1 pour les paquets glibc 2.3.2 pour "lib64") qui est la base d'une RHEL 3 (sortie 9/2003). La RHEL 3 supporte le mix i386 amd64 (plus ou moins bien). Par exemple mozilla et openoffice dans RHEL 3 pour amd64 est compilé pour i386.
> C'est pour ça que mdk depuis 2 ans travaille sur ça, en placant les libs 64 bits dans lib64.
Tout le monde fait ça...
# 20 % plus vite qu'un IA32 ?!
Posté par Ayrton . Évalué à -4.
Les applications Linux tournant sur AMD64 sont en moyenne 20% plus rapides que lorsqu'elles tournent sur un système 32-bit traditionnel
C'est bien évidemment faux.
Ou alors on m'aurait menti...
tout en conservant une compatibilité 32-bit totale.
Ça veut dire quoi ?
Que les applications AMD64 peuvent tourner sur un i686 ?
Que mozilla ou OOo pour AMD64 est compatible avec la version pour i686 ? Heureusement...
Pas de version download ?
[^] # Re: 20 % plus vite qu'un IA32 ?!
Posté par nicolinux . Évalué à 4.
tout en conservant une compatibilité 32-bit totale.
Ça veut dire quoi ?
Que les applications AMD64 peuvent tourner sur un i686 ?
Que mozilla ou OOo pour AMD64 est compatible avec la version pour i686 ? Heureusement...
Pas de version download ?
-------------------------------------------------------------------------------------------------------------
je crois bien que c l'inverse, tu peux lancer des applis 32bits sur ce proc 64bits
style lancer win32 ou meme mdk10 pour IA32
mais peut etre m'aurait on mentis aussi ;)
[^] # Re: 20 % plus vite qu'un IA32 ?!
Posté par Ayrton . Évalué à -4.
C'est ce que dit la page des aractéristiques :
De plus, Mandrakelinux 10.0 Official pour AMD64 assure une parfaite compatibilité avec toutes les applications 32 bits.
Pas très sérieux le communiqué de presse.
[^] # Re: 20 % plus vite qu'un IA32 ?!
Posté par Epsos . Évalué à -1.
[^] # Re: 20 % plus vite qu'un IA32 ?!
Posté par Ayrton . Évalué à -1.
Va comprendre Charles...
[^] # Re: 20 % plus vite qu'un IA32 ?!
Posté par thedidouille . Évalué à -2.
[^] # Re: 20 % plus vite qu'un IA32 ?!
Posté par Ayrton . Évalué à -4.
Je sais seulement qu'un AMD64 est plus rapide en mode 64bits qu'en mode 32bits. Par contre qu'un AMD64 à X GHz soit globalement plus rapide de 20 % qu'un athlon (32 bits) à la même fréquence, j'ai jamais vu ça. C'est même l'inverse (de l'ordre de 10 %).
[^] # Re: 20 % plus vite qu'un IA32 ?!
Posté par thedidouille . Évalué à 0.
et d'un, c'est pas comparable, et de 2, ca veut rien dire(puis c'est faux). Pour te repondre il faudrait deja que tu saches comment grossierement ca ce passe. En tout cas, ca accelere pas l'internet.
"Par contre qu'un AMD64 à X GHz soit globalement plus rapide de 20 % qu'un athlon (32 bits) à la même fréquence, j'ai jamais vu ça"
dans le cas ou tu recompiles ton application, tu as + de registres a ta disposition, ce qui explique ces gains de perf.
tu devrais te remettre a la F1.
[^] # Re: 20 % plus vite qu'un IA32 ?!
Posté par Ayrton . Évalué à 3.
Les applis compilées pour i386 peuvent tourner sur amd64 (c'est aussi l'objectif de l'amd64 ... ).
> ce qui explique ces gains de perf.
Direction google.
J'ai raté des épisodes de l'amd64. J'en étais resté aux benchs de l'opteron (prométeurs mais n'affolant pas les chronos) et aux performances très moyennes de l'IA64 pour poste de travail (en fait tous les cpu 64 bits étaient généralement battus par les 32 bits en poste de travail (sauf flottant, etc)).
J'étais resté fixé sur le dernier test de lwn.net :
http://lwn.net/Articles/79036/(...)
Your editor was naturally interested in performance issues. To that end, he built a version of bzip2 in both 64-bit and 32-bit mode and compared the results. Both compression and decompression ran about 10% faster in the 64-bit mode. With the x86_64 processor, better performance is generally expected in the native mode, mainly due to the additional registers which are available. The executable size and memory usage in 64-bit mode were larger, but not by much. A second test, using the SoundTouch library yielded a surprise, however: changing the tempo of a large sound file ran in less than 1/5 the time in 32-bit mode. The Athlon64 processor, it would seem, runs certain operations far more slowly in 64-bit mode; your editor has not, yet, had the time to track this one down.
Mais :
http://www.hardware.fr/articles/478/page13.html(...)
En attendant, on peut toujours constater un état de fait. Les améliorations apportées à l´architecture K7 au sein de l´architecture K8 sont plus que substantielles, les gains entre un Athlon XP 3200+ et un Athlon 64 3200+ étant de l´ordre de la dizaine de %, et ce malgré une fréquence inférieure de 200 MHz pour l´Athlon 64. De plus, l´Athlon 64 en a encore sous la pédale via l´AMD64 ISA, qui devrait apporter lorsqu´il sera utilisé un gain notable de performances, notamment via les nouveaux registres qu´il permet d´utiliser.
En tout cas une chose est sûre, en l´état actuel des choses, les Athlon 64 ne sont pas des tueurs de P4.
Voir aussi les commentaires de :
http://lwn.net/Articles/83580/(...)
http://www6.tomshardware.com/cpu/20040419/cpu-scaling-22.html(...)
The Athlon64 FX's integrated memory controller repeatedly showed off its strengths. Whenever users want to play 3D games (Comanche, Serious Sam, Splinter Cell, Unreal Tournament 2003, Wolfenstein Enemy Territory, and X2), the Pentium 4 Extreme Edition is only runner-up. Also, the FX holds a sizeable lead when it comes to data compression with WinRAR, compilation of a C++ project with Visual Studio.net and Mathematica. Even during testing at high clock rates, these strengths were quite obvious.
On the other hand, we should also point out the advantages of the Pentium 4 EE.
A fréquence équivalent un amd64 est plus rapide qu'un athlon. C'est sûr. Donc j'avais faux :-( . Mais un amd64 peut-être battu par un P4. Donc ...
La fréquence n'est pas tout et un comparatif performance/prix serait un plus. Sous oublier l'avantage d'avoir un vrai 64 bits.
Ceci est un commentaire embarrassé.
[^] # Re: 20 % plus vite qu'un IA32 ?!
Posté par jujubinche007 . Évalué à 1.
La fréquence n'est pas tout et un comparatif performance/prix"
Ben oui, mais l'AMD, justement, tourne à (au moins) 1Ghz de moins que le P4 equivalent.
Donc oui, la frequence n'est pas tout, et l'architecture AMD semble immensement plus efficace que celle d'Intel, et ceci en "pur" 32bits ... Alors je me dis, en mode "natif", ça doit pas mal marcher sur pas mal de trucs (3D, compression en tout genre, traitement d'images ... ) ... y'a quand même pas mal d'application de tous les jours qui peuvent beneficier de tout ça ... non ?
[^] # Re: 20 % plus vite qu'un IA32 ?!
Posté par Pascal Terjan (site web personnel) . Évalué à 1.
[^] # Re: 20 % plus vite qu'un IA32 ?!
Posté par 007 . Évalué à -2.
Warly va peut-être passer ici pour nous dire que c'est encore un "délire" marketing. En attendant, soyons chut (certified XP save).
> Pas de version download ?
Pas vu de version download de la 9.2 pour amd64. Donc ...
[^] # Re: 20 % plus vite qu'un IA32 ?!
Posté par ckyl . Évalué à 3.
Si l'appli est recompilée ce n'est pas forcement etonnant. Il y a par exemple des applis qui travaillent beaucoup sur des valeurs de 64 bits, donc avoir un proc 64 ca aide un peu :-)
Par contre une appli compilée pour x86 et lancée sur un AMD64 j'ai des doutes hormis la différence de puissance brut du proc étant donné qu'il y a une compatilibilité stricte et totale des x86 jusqu'aux premieres versions d'il y a 20 ans.
Autrement FreeBSD : Athlon64 3200+ vs Pentium4 3.2E.
http://www.thejemreport.com/modules.php?op=modload&name=News&am(...)
Bench interessant car ne fournissant pas de jolis graphes ni de conclusions faciles mais laisse le lecteur se faire une idée.
# Invocation d'un démon mineur du marketing
Posté par Jul (site web personnel) . Évalué à -4.
C'est marrant mandrake c'est mono-plate-forme (x86) et en plus pas totalement (>=pentium)
Maintenant, ils s'ouvrent à l'AMD 64, je ne sais quoi dire ; pourquoi quand on a un noyau aussi portable et une couche système peu dépendante du hardware s'enfermer ainsi ?
Si un dieu du marketing pouvait me le dire : je serais heureux, je sens bien que je ne saisis pas la puissance de la stratégie mandrakienne.
(NB j'ai autant de mal avec Red Hat remarquez).
[^] # Re: Invocation d'un démon mineur du marketing
Posté par 007 . Évalué à 3.
De mémoire mais je peux me tromper, Mandrake a déjà fait du IA64 , ppc et sparc (les deux dernier sont abandonnés maintenant je crois). Donc, c'est pas nouveau.
> Si un dieu du marketing pouvait me le dire
Inutile d'être du marketing. Porter une distribution c'est du boulot. Il y a l'installeur qui peut changer significativement par exemple. Les applications sont moins testées sur les plates-formes "exotiques". Le noyau est développé en premier pour i386. Il faut faire des boîtes, doc, etc plus ou moins spécifique par architecture. Il faut du matériel. Le support et les developpeurs de la distribution doivent connaitre plusieurs architectures. Etc.
> j'ai autant de mal avec Red Hat remarquez
Fedora : i386 et amd64
RHEL : AMD64, i386, ia64, ppc, s390, s390x
Pour RHEL, c'est normal la distribution sort moins souvent.
Toutes ces architectures sont aussi couvertes par la branche de développement de Fedora (anciennement Rawhide). Tout est compilé mais pas nécessairement testé tous jours voir toutes les semaines...
Je comprend RedHat car ils ont un volume, une image et du support qui leur permettent de développer et vendre du s390 à 15 000 ou 18 000 $ par an. Ça reste rentable même avec peu d'unitée.
Je comprend Mandrake qui ne se disperse pas dans des niches très coûteuses et risquées financièrement pour eux.
[^] # Re: Invocation d'un démon mineur du marketing
Posté par Olivier Grisel (site web personnel) . Évalué à 5.
Perso je prefere Debian qui a plus de paquets à jour en ppc.
[^] # Re: Invocation d'un démon mineur du marketing
Posté par puxor . Évalué à 2.
C'est clair. Je pourrais parler de debian:
1. qui supporte 11 architectures
2. qui est en train d'écrire un installeur très prometteur qui marche déjà sur 9 de ces archis (il me semble)
3. qui s'occupe du portage de Xfree sur ces même 11 archis (l'équipe de xfree ne s'occupant que des x86).
4. qui s'occupe du kernel (m'enfin le 2.6 de debian est tout pourri je trouve)
5. sans compter le portage de tous les autres softs (et y'en a, dans debian: # apt-cache stats: Nombre total de paquets : 20167, ok y'a des doublons dont KDE mais quand même)
Mais on va me traiter d'intégriste (zut, on me dit dans mon oreillette que c'est déjà trop tard)
Pour faire des portages pour plus que deux ou trois archis, avec les installeurs qui vont bien et tout, il faut au moins:
1. bcp de volonté voire d'acharnement, de stress, de deadlines impossible à satisfaire, etc...
2. BCP de main d'oeuvre compétente pour bosser (testage/patchage/trolls^Wdiscussions techniques) mais aussi pour encadrer (la participation d'ordre technique n'est pas suffisante)
3. quantité de matos très différent (par architecture, hein!)
4. une bonne infrastructure de gestion des bugs, de build automatiques, etc... construite pdt des années, rentable techniquement mais pas économiquement.
Évidemment ce n'est ni faisable ni intéressant pour une société. Ne pas être une entité commerciale est un énorme avantage de debian (c'est aussi un problème, exemple: ne pouvoir payer personne pour prendre en charge les tâches nécessaires, mais peu attirantes)
Voilà voilà, donc honnêtement si les sociétés gravitant autour de linux ne font quasiment que du x86, c'est pas moi qui leur en voudrai.
"Je comprend Mandrake qui ne se disperse pas dans des niches très coûteuses et risquées financièrement pour eux"
bof, ça va même pas jusqu'au risque financier. La non-rentabilité est évidente dès qu'on creuse 5 minutes. Une quantité de boulot et de financement incroyable pour combler peu de demandes. C'est même pas un vrai marché. Y'a que les bigots^Wélitistes^Wdécideurs de chez debian pour faire ça (genre, hppa et m68k, je me demande qui utilise ça pour une *vraie* raison, autre que s'amuser avec une vieille machine ou une vieille archi qui faisait rêver quand on était jeunes)
[^] # Re: Invocation d'un démon mineur du marketing
Posté par Jul (site web personnel) . Évalué à -1.
Correcte étant défini par :
- un soin apporté à l'intégration (hiérarchie des fichiers de conf, paquets testés, install par défaut)
- multi-plateforme ,
- correctement documentée (ça coûte cher et c'est pas rentable la doc, hein ?),
- indépendante et donc pérenne (pas trop de risque que debian se fasse racheter par microsoft, hein ? )
- respectueuses des utilisateurs (et non des actionnaires) ;
- correction des bug rapides, et accès pour tous aux listes de diffusions concernant la sécurité ;
....
Mais l'entreprise n'est elle pas sensée être l'endroit où on fait le mieux les choses ?
[^] # Re: Invocation d'un démon mineur du marketing
Posté par Jul (site web personnel) . Évalué à 0.
De mémoire mais je peux me tromper, Mandrake a déjà fait du IA64 , ppc et sparc (les deux dernier sont abandonnés maintenant je crois). Donc, c'est pas nouveau.
Exact, la 9.1 au moins était certifiée même sur les RS6000 et pour le reste aussi. Autant pour moi.
Je ne comprend toujours pas pourquoi si il est si embêtant de faire du spécifique, pourquoi ils ont tout recompilé pour architecture pentium pour le x86 ?
Le noyau est développé en premier pour i386. Il faut faire des boîtes, doc, etc plus ou moins spécifique par architecture. Il faut du matériel. Le support et les developpeurs de la distribution doivent connaitre plusieurs architectures. Etc.
Oui il est développé pour 386 par pour 586 :) comme la plupart des applis.
C'est du logiciel libre, ils n'ont pas besoin de faire du spécifique ? J'espère que mandrake ne s'amuse pas à redevélopper tous les logiciels du libre, je veux dire le support et l'intégration (qui sont souvent faciliter par les makefiles, automake ....) c'est leur métier. Si les développeurs font de mauvais logiciel, c'est pas à eux de maintenir le soft quand même ? Manfrake embauche des spécialistes de l'intégration pas des développeurs j'espère.
Et puis openBSD par exemple à 50 gros commiteurs ils font bien plus d'archi, ils traduisent les docs, ils écrivent les pages de manuels manquantes, et ils ont même le temps de troller sur la dernière licence apache. Tiens d'ailleurs il paraît qu'ils vont passer sur IA64 (ça doit être obsolète ce truc)
j'ai autant de mal avec Red Hat remarquez
Je veux dire, entre RH server, RHEL, foedora, leur certification à la MS (valable pour une distrib donnée)... ils se diversifient tellement que j'aurais vraiment besoin que l'on m'explique RH aujourd'hui.
On dirait que ces entreprises changent d'activité tous les 6 mois,
La mode est à la formation, ils font de la formation,
La mode est au «professional services» ils font du PS
La mode est au distrib sur mesure ...
La mode est au contrat de support ...
La mode est au développement spécifique ...
Un coup ils font moult archi, le lendemain ils reviennent en arrière.
[^] # Re: Invocation d'un démon mineur du marketing
Posté par wismerhill . Évalué à 1.
Si tu veux une distrib à installer sur ton 486 tu peux prendre une debian, moi je préfère quelque chose d'au moins un peu optimisé pour ma machine.
[^] # Re: Invocation d'un démon mineur du marketing
Posté par Misc (site web personnel) . Évalué à 1.
> spécifique, pourquoi ils ont tout recompilé pour architecture pentium pour le
> x86 ?
Parce que c'est recompilé depuis le début en i586. Ensuite, c'est pas tant de developper en spécifique, que de faire plusieurs archis, car, automatiquement, il faut faire plus de test, et vérifié que les patchs et fixs ne cassent pas un truc sur une autre architecture. Tout ça pour un gain nuls.
Peut être que pour la plupart du monde, limiter les dépenses est néfaste, mais quand on a des gens à payer, pour les faire vivre, ça semble tout d'un coup moins idiot.
> Oui il est développé pour 386 par pour 586 :) comme la plupart des applis.
Il y a pourtant des parties du code qui prennent en compte le mmx, dispo à partir de pentium, si je me souvient bien. Et pareil pour la glibc, qui a des parties optimisés i686, chargé dynamiquement grace au loader (voir fichier dans /lib/i686/ )
> Manfrake embauche des spécialistes de l'intégration pas des développeurs
> j'espère.
Ben je sais pas, mais je suppose que les gens qui font les outils mandrake sont des développeurs, tout comme les gens qui travailles sur le noyau ou kde. Du moins, c'est l'impression que j'ai.
Mais on pourrait dire, si on voulait lancer un troll que si mdk embauche des devs, c'est surtout signe que c'est mal intégré, et que si mdk embauche des intégrateurs, c'est dans ce cas signe qu'elle n'aide pas assez le libre en ne developpant que des trucs pour elles ( car en général, l'intégration d'un paquet bénéficie à moins de monde qu'un patch )
[^] # Re: Invocation d'un démon mineur du marketing
Posté par Raphaël G. (site web personnel) . Évalué à 1.
J'ai surtout l'impression qu'il embauchent des dévelopeurs, avec des capacités d'intégrateurs...
De plus je vois vraiment pas l'utilité d'avoir une distrib en i286 pour le plaisir, que personne va utiliser...
Parce que franchement je vois pas qui va s'ammuser a faire tourner une mandrake sur un i486 sauf pour le fun...
# Prix et support
Posté par Ayrton . Évalué à 5.
Content
- 4 CDs
Support
- No support included for this product
[...]
Price : 119.9 EUR
Pour 119,9 t'as plus rien : 4 CD et pas de support.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.