Voilà, la nouvelle version (et version de transition vers le nouveau calendrier) de la distro linux au nom le plus moche est dispo. Les clubistes et contributeurs peuvent la télécharger en avance.
Nouveautés :
- Linux kernel 2.6.11.6
- KDE 3.3.2 (avec des "backports" de la version 3.4, dont kpdf)
- GNOME 2.8.3
- Firefox 1.0.2
- GCC 3.4.3
- The GIMP 2.2
- Cdrecord 2.01.01a21 (avec support DVD+R double-couche)
- OpenOffice.org 1.1.4
- MySQL 4.1.11
- et bien d'autres...
Voilà. Maintenant battez-vous pour la news.
Journal Mandriva Linux Limited Edition 2005 released
13
avr.
2005
# noms moches
Posté par Antoine . Évalué à 8.
Il se murmure que la prochaine version s'appellera "Mandroid Linux 2006 Brutal Donkey Edition (Special Mix)".
[^] # Re: noms moches
Posté par eon2004 . Évalué à 0.
Comme quoi faire pire est devenu un challenge :-(
[^] # Re: noms moches
Posté par drcanard . Évalué à 4.
# Et le plus important...
Posté par sirrus . Évalué à 3.
http://www.mandrakeclub.com/article.php?sid=3632&mode=nocomment(...)
[^] # Re: Et le plus important...
Posté par Gniarf . Évalué à 0.
pour éviter d'aller sur attrapecouillonsclub.com
[^] # Re: Et le plus important...
Posté par fabb . Évalué à -1.
Ils sont culotté dans mandr(iva|ake) :
Limited Edition 2005 is the only Linux system to allow the seamless installation and
running of 32-bit applications on 64-bit platforms.
S'approprier le boulot des autres est classique chez eux.
[^] # Re: Et le plus important...
Posté par Gwenole Beauchesne . Évalué à 6.
La nouveauté de la 2005 étant la possibilité de mixer des packages de -devel pour développer à la fois des applications 32-bit et 64-bit, sans chroot, sans conflit lors de l'installation (non simultanée) desdits packages. Tu prends juste les packages 32-bit, tu installes, ça marche (e.g. GNOME2 & QT). Ce n'est pas encore possible sous Red Hat: cf. http://www.redhat.com/archives/amd64-list/2005-February/msg00008.html par exemple, qui n'a pas eu de réponse.
[^] # Re: Et le plus important...
Posté par fabb . Évalué à 1.
Red Hat "mixe" 32 bits et 64 bits depuis RHEL 3 (basé sur RH9). De plus il y a eu une "technologie preview" (gingin64) basée sur RH9 bien avant la sortie de RHEL 3.
C'est Red Hat qui a ajouté le support multi-arch dans rpm et dans la libc. Red Hat maintient pratiquement à 100 % rpm et à 70 % la libc.
> Red Hat commence à peine à séparer davantage les libs au niveau package
Rien n'a changé sur ce point (du moins récemment) et tu fais des mélanges. rpm supporte d'avoir deux fois le même fichier dans deux paquets différents.
Donc lib...i386.rpm et lib...x86_64.rpm qui fournit tous les deux le même fichier peut-être installé en parallèle (c'est nécessaire pour les librairies qui dépendent de données dans /usr/share/... ou d'un fichier de config dans /etc/...). Sous Red Hat/Fedora, toutes les lib x86_64 sont installées dans ../lib64 .
> Sous Mandriva Linux c'était déjà possible depuis longtemps sans repackager les libs et grâce à une politique de libification des packages (à la Debian)
Tu mélanges avec la possibilité d'avoir des versions différentes de la même librairie sans "troubler" rpm.
Red Hat le fait quand c'est nécessaire mais ne le fait pas systématiquement.
> Red Hat commence à peine à séparer davantage les libs au niveau package (cf. packages de la forme -libs)
Ce qui est du pipeau car Red Hat fait ça pour les besoins de mixer i386/x86_64 depuis RHEL 3 (et avant évidemment ; phase beta et preview gingin64).
Pour Fedora il y a FC1 pour AMD64 qui est sorti depuis un bon moment :
http://fr2.rpmfind.net/linux/fedora/core/1/x86_64/os/Fedora/RPMS/(...)
Plus de 60 paquets en i386.
Donc rien de nouveau.
> SuSE repackagent les libs 32-bit.
Red Hat ne fait pas ça. Le même paquet est fait pour i386 (--target=i386) et x86_64 (--target=x86_64). C'est tout. Il n'y a pas de paquet spécifique pour x86_64.
> La nouveauté de la 2005 étant la possibilité de mixer des packages de -devel pour développer à la fois des applications 32-bit et 64-bit, sans chroot, sans conflit lors de l'installation (non simultanée) desdits packages.
Avec le "non simultanée", c'est pareil pour Red Hat.
> http://www.redhat.com/archives/amd64-list/2005-February/msg00008.ht(...)
C'était un bug (tu sais, le truc que tout le monde rencontre), il a été corrigé :
http://www.redhat.com/archives/amd64-list/2005-February/msg00004.ht(...)
> par exemple, qui n'a pas eu de réponse.
Voir l'url que j'ai donné.
[^] # Re: Et le plus important...
Posté par fabb . Évalué à 1.
De plus, l'utilisateur reconnais son erreur "Download the right package and it installs fine.". Manifestement son système n'est pas maintenu à jour (argh).
Par contre RHEL ne permet pas de développer du i386 et AMD64 en même temps. C'est comme Mandriva.
[^] # Re: Et le plus important...
Posté par Gwenole Beauchesne . Évalué à 3.
À l'époque, tu étais obligé d'installer les 2 en même temps avec la même version et même release exactement. Sous Mandrake Linux tu pouvais déjà faire vivre les 2 séparemment, indifféremment.
Rien n'a changé sur ce point (du moins récemment) et tu fais des mélanges
Lis par exemple les commentaires de Mike Harris dans ses packages. Ils sont en train de limiter les libs à uniquement des packages -libs pour limiter les conflits pour ce qui est en dehors de */lib ou */lib64.
Avec le "non simultanée", c'est pareil pour Red Hat.
Non, lis bien le code de rpm. Il y a du code spécifique qui te permet de préférer un binaire marqué ELF64 quand tu installes 2 packages 32-bit et 64-bit en même temps. Autrement, ça conflicte.
C'était un bug (tu sais, le truc que tout le monde rencontre), il a été corrigé
Lis bien, il voulait glib-config 32- et 64-bit, c'est donc glib-devel, pas glib. Et glib-devel conflicte.
Par contre RHEL ne permet pas de développer du i386 et AMD64 en même temps. C'est comme Mandriva.
Bien sûr que si que c'est possible sous Mandriva. Je peux rebuilder evolution2 par exemple en 32-bit et en 64-bit sans problème, sans désinstaller de package. Je répète, la nouveauté de Mandriva Linux 2005 c'est que tu peux justement développer des programmes 32-bit et 64-bit en même temps, sans désinstaller de packages, sans chroot.
Essaie par exemple d'installer en même temps un glib-devel 32-bit et 64-bit sous FC4 ou RHEL. Tu ne peux pas. Au mieux, rpm va installer 1 des 2 /usr/bin/glib-config, ce qui sera incorrect pour l'autre arch (cf. sortie de --cflags & co).
[^] # Re: Et le plus important...
Posté par fabb . Évalué à 1.
Non. Tu installes l'un ou l'autre ou les deux en même temps.
Tu n'es pas obligé.
> avec la même version et même release exactement.
Ça dépend. Mais en pratique oui.
> Sous Mandrake Linux tu pouvais déjà faire vivre les 2 séparemment, indifféremment.
Idem.
> Lis par exemple les commentaires de Mike Harris dans ses packages. Ils sont en train de limiter les libs à uniquement des packages -libs pour limiter les conflits pour ce qui est en dehors de */lib ou */lib64.
C'est comme ça depuis longtemps. Ce n'est pas nouveau. Toi tu dis que c'est nouveau. C'est sur ce point que je ne suis pas d'accord.
> Non, lis bien le code de rpm. Il y a du code spécifique qui te permet de préférer un binaire marqué ELF64 quand tu installes 2 packages 32-bit et 64-bit en même temps. Autrement, ça conflicte.
Par défaut il installe ELF64. En quoi ça te dérange ? Tu veux que sur un système AMD64 par défaut il installes du i386 ?
Ça n'a pas de sens.
De plus j'aimerai que tu me trouves ce code rpm. Tu dois parler de yum ou up2date.
Avec yum ou up2date peut peut installer un paquet i386 sur un système amd64 avec :
yum install toto....i386
Avec rpm s'est tout bêtement :
rpm -i toto...i386.rpm
Si tu fais "rpm -i toto...i386.rpm toto...x86_64.rpm", il les installera s'il ne sont pas en comflit.
> Autrement, ça conflict
Ça dépend. Pour les lib, ça ne "conflict" pas.
> Lis bien, il voulait glib-config 32- et 64-bit, c'est donc glib-devel, pas glib. Et glib-devel conflicte.
Comme Mandriva. C'est toi même qui l'a dit :
- "sans conflit lors de l'installation (non simultanée) desdits packages."
Où veux tu en venir ?
> Essaie par exemple d'installer en même temps un glib-devel 32-bit et 64-bit sous FC4 ou RHEL.
Essais avec Mandriva :
Par quel miracle il est possible d'installer lib64glib2.0._0-devel avec libglib2.0_0-devel alors qu'il y a des fichiers en conflit ?
Faudrait peut-être arrêter de pipeauter.
[^] # Re: Et le plus important...
Posté par Gwenole Beauchesne . Évalué à 2.
Par exemple, "rpm-libs" est apparu avec rpm 4.2.3. Bon, après, on peut effectivement interpréter "longtemps". bzip2-libs existe par exemple depuis GinGin64 effectivement.
De plus j'aimerai que tu me trouves ce code rpm.
Je parle de rpm, c'est pourtant marqué en clair dans les commentaires, et très lisible dans les sources.
Si tu fais "rpm -i toto...i386.rpm toto...x86_64.rpm", il les installera s'il ne sont pas en comflit.
En cas de conflit, et vu que tu spécifies les 2 packages sur la même ligne de commande, rpm ignorera les conflits et installera les binaires elf64 qu'il trouve. Bien sûr, d'autre conflits peuvent survenir (/usr/share/*), dans ce cas là, ça conflicte réellement. La résolution des conflits elf64/elf32 est transparente. C'est pas forcément une bonne chose (cf. plus bas) mais ça fonctionne.
Ça dépend. Pour les lib, ça ne "conflict" pas.
Pourvu que tu n'aies pas de /usr/share/doc/ par exemple qui diffère d'un chouia. Avec une approche où le package de libs s'appelle différemment, tu ne peux pas avoir de conflit pour les docs par exemple.
- "sans conflit lors de l'installation (non simultanée) desdits packages."
Où veux tu en venir ?
En simultané (rpm -i truc.i586.rpm truc.x86_64.rpm), c'est naturel, ça marchera quasiment tout le temps avec la résolution de conflicts implicite entre elf32/elf64 et du fait que tu spécifies une même version-release dans les 2 cas. Par non simultanée, j'entends que tu installes plus tard. i.e. pas sur la même ligne de commande, i.e. ça peut être une version-release différente mais dans la vraie vie l'utilisateur voudra avoir une installation cohérente des libs 32-bit et 64-bit de toutes façons.
Deuxième chose, installer c'est bien, pouvoir mettre à jour c'est mieux. Et là, le système de résolution de conflits implicite est moins flexible.
Par quel miracle il est possible d'installer lib64glib2.0._0-devel avec libglib2.0_0-devel alors qu'il y a des fichiers en conflit ?
D'une part, tu as une manière typiquement de toi et magistrale de contourner les réponses. Tu peux changer de pseudo, on te reconnaîtra tout le temps. ;-) J'ai dit "glib-devel", tu regardes correctement et tu réalises que c'est glib 1.2. D'autre part, dans le cas de glib2.0-devel, les conflits sont ignorés car les binaires glib-genmarshal et gobject-query sont marqués elf64 donc préférés à l'install. i.e. si tu installes la version 32-bit après la 64-bit, l'ancien binaire 64-bit est conservé.
Par ailleurs, je n'aime pas trop ce système de résolution implicite des conflits rpm à préférer par défaut les binaires 64-bit sans warning. Justement parce que c'est implicite, tu ne sais plus qu'il existait un conflit potentiel. C'est assez dangereux pour des générateurs car le code (source C par exemple) peut devoir être différent suivant que tu veux du 32-bit ou 64-bit. Heureusement, qu'on vérifie ce genre de choses. Le cas de glib2.0-devel a l'air sain i.e. ces 2 binaires sont censés être arch-indépendants (c'est pour générer du code faisant du marshaling).
Dans le cas où des binaires, ou bien des includes, ont un comportement différent suivant que tu veux du 32-bit ou 64-bit, Mandriva Linux a tout un dispositif pour différencier cela automatiquement (sauf pour le packager mais il existe des outils pour essayer de vérifier cela statiquement au build). De fait, tu as par exemple /usr/bin/multiarch-i386-linux/glib-config et /usr/bin/multiarch-x86_64-linux/glib-config. Tu vois clairement que différencier les 2 est important car --cflags doit fournir des résultats différents suivant que tu buildes du 32-bit ou 64-bit. Pareil pour les includes, e.g. #define QT_POINTER_SIZE 4 ou 8.
Au final, tu peux rebuilder des packages 32-bit aussi simplement que linux32 rpm --rebuild evolution.rpm (pour avoir du i586.rpm) ou rpm --rebuild evolution.rpm (pour avoir du x86_64.rpm).
[^] # Re: Et le plus important...
Posté par fabb . Évalué à 1.
Et alors ?
> Je parle de rpm, c'est pourtant marqué en clair dans les commentaires, et très lisible dans les sources.
T'es gentil mais t'as vue la taille des sources de rpm ? Je ne crois pas.
Donnes au moins le nom fichier puisque c'est si évident pour toi.
> En cas de conflit, et vu que tu spécifies les 2 packages sur la même ligne de commande, rpm ignorera les conflits et installera les binaires elf64 qu'il trouve.
Non. En cas de comflit, rpm s'arrête. rpm est un outils bas niveau et pas "smart".
Puisque tu connais à fond les sources de rpm, tu dois bien pouvoir me dire où rpm fait fait :-)
> Pourvu que tu n'aies pas de /usr/share/doc/ par exemple qui diffère d'un chouia. Avec une approche où le package de libs s'appelle différemment, tu ne peux pas avoir de conflit pour les docs par exemple.
C'est là la grande nouveauté ?
Formidable. Pour libglib-devel (de mandriva), il y a en commun :
/usr/bin
/usr/include/glib-2.0
/usr/share/aclocal
/usr/share/gtk-doc
/usr/share/man
Pour libglib :
/etc/profile.d
/usr/share/locale
Alors ton "/usr/share/doc" me fait bien rire alors qu'il suffit qu'un fichier .mo ou la doc dans /usr/share/gtk-doc de modifié pour foutre le bordel. C'est comme ça dans Mandriva !
> ça peut être une version-release différente
Mandrake a le même problème (sauf pour /usr/share/doc ; super !).
> Deuxième chose, installer c'est bien, pouvoir mettre à jour c'est mieux. Et là, le système de résolution de conflits implicite est moins flexible.
Même problème pour Mandriva puisqu'il y a des fichiers en commun.
> D'autre part, dans le cas de glib2.0-devel, les conflits sont ignorés car les binaires glib-genmarshal et gobject-query sont marqués elf64 donc préférés à l'install. i.e. si tu installes la version 32-bit après la 64-bit, l'ancien binaire 64-bit est conservé.
Non. Ça n'a tout simplement pas de sens de faire ça.
Exemple :
- tu as la version i386
- tu ajoute la version amd64 (qui écrase la version i386)
- tu retire la version amd64
=> il se passe quoi ?
De plus pour glib, ça n'a pas de sens. Les programmes dans /usr/bin/ sont spécifiques, donnent des données spécifiques (différent pour i386 et x86_64).
> J'ai dit "glib-devel"
Il n'y a pas de paquet glib-devel dans Mandriva LE 2005 !
> tu regardes correctement et tu réalises que c'est glib 1.2.
De quoi tu parles ?
J'ai seulement regarder glib 2.0.
> Par ailleurs, je n'aime pas trop ce système de résolution implicite des conflits rpm à préférer par défaut les binaires 64-bit sans warning.
rpm ne le fait pas. Trouves moi le code de rpm si c'est si simple.
> De fait, tu as par exemple /usr/bin/multiarch-i386-linux/glib-config et /usr/bin/multiarch-x86_64-linux/glib-config.
Ce n'est pas suffisant. Vraiment pas.
> Au final, tu peux rebuilder des packages 32-bit aussi simplement que linux32 rpm --rebuild evolution.rpm (pour avoir du i586.rpm) ou rpm --rebuild evolution.rpm (pour avoir du x86_64.rpm).
Comme Red Hat, mais t'as seulement les *-devel i386 ou amd64 d'installé à la foi. Et c'est idem pour Mandriva !
Ironie :
[admin@one fedora]$ ll -i /usr/bin/linux32 /usr/bin/setarch
83787 -r-xr-xr-x 4 root root 6728 nov 3 20:41 /usr/bin/linux32
83787 -r-xr-xr-x 4 root root 6728 nov 3 20:41 /usr/bin/setarch
man linux32 :
man setarch :
setarch.c :
Mandrake n'a rien inventé.
[^] # Re: Et le plus important...
Posté par fabb . Évalué à 1.
> /* Copyright (C) 2003 Red Hat, Inc. */
Notes bien le 2003.
Le changelog du .spec :
Ça a été fait durant gingin64 et en phase de développement de RHEL 3.
Rien de nouveau.
[^] # Re: Et le plus important...
Posté par fabb . Évalué à 2.
Il y a un patch :
Impressionnant.
[^] # Re: Et le plus important...
Posté par Gwenole Beauchesne . Évalué à 2.
lib/transaction.c c'est marqué dedans à 2 reprises. En fait, y'a un cas pour les updates, un autre quand tu fais une installe pure (-i).
Non. En cas de comflit, rpm s'arrête. rpm est un outils bas niveau et pas "smart".
Regarde les sources ou bien lis au moins le changelog. T'avais l'air pourtant à fond Red Hat, je ne comprends pas comment tu n'aies pas pu voir cela.
l n'y a pas de paquet glib-devel dans Mandriva LE 2005 !
Mais bon sang, l'exemple du gars qui n'a pas eu de réponse pour ce cas là, émettait l'hypothèse de savoir comment c'était géré dans Fedora pour "glib-devel" ! glib-devel dans Fedora c'est glib 1.2.10. Dans Mandriva, tu vois pourtant un package libglib1.2-devel et lib64glib1.2-devel.
Ce n'est pas suffisant. Vraiment pas.
Ah ben si quand même, y'a que ceux là (+ un include) qui diffèrent, donc tu les sépares de sorte qu'une installation simultanée des 2 ne puisse conflicter. Pour glib2, comme expliqué, avec le système de résolution implicite des conflits pour elf64/elf32 ça s'installe. Par chance, tu auras remarqué que ce que ça fait est arch-indépendant, pour glib2 je le précise encore, pour 32 ou 64-bit. Tout simplement parce que ça génère du code C et l'implémentation réelle du marshaling sera déportée par petits bouts dans les libs respectives une fois le code généré compilé.
Comme Red Hat, mais t'as seulement les *-devel i386 ou amd64 d'installé à la foi. Et c'est idem pour Mandriva !
Je t'explique depuis le temps que sous Mandriva, tu installes les 2 à la fois. Bon, tu ne veux pas télécharger et essayer par toi même? Parce que je m'efforce à t'expliquer mais tu ne comprends toujours pas. Essaie, ce sera sans doute limpide...
Au fait, linux32 rpm --rebuild truc.rpm ne fonctionnera pas sous Fedora parce que tu aurais besoin en plus de spécificier CC="gcc -m32" et éventuellement CXX="g++ -m32". Pas besoin sous Mandriva. ;-) GCC et d'autres outils ont été patchés pour être linux32 aware.
Par ailleurs, le rpm x86_64 de Fedora/RH n'a aucune config 32-bit pour compiler (cf. les /usr/lib/rpm/i386-linux/macros & co).
man linux32
Je ne vois pas pourquoi tu sors ça. linux32 te permets de spécifier une personnalité 32-bit. De fait, rpm quand il fera son uname -m saura que c'est i686 et donc chopera les configs 32-bit pour compiler.
Pour ton info, linux32 de x86-64.org était utilisé initialement utilisé. C'est un programme trivial cela dit au passage, donc inutile d'en réécrire un pour chaque distrib. Celui de x86-64.org était écrit par SuSE. Bon après, setarch est apparu pour couvrir plus d'architectures.
Mandrake n'a rien inventé
Où ai-je dit que Mandrake a créé l'outil linux32? Bon sang, mais t'es terrible toi pour détourner les propos des gens. Le plus drôle (vraiment c'est comique là parce que tu es un spécimen) c'est que tu sors après tout un tas de patches, docs sur un truc insignifiant qui n'a rien à voir avec le propos initial. Juste avec un propos que tu as mal interprété ou bien détourné de sens encore une fois.
[^] # Re: Et le plus important...
Posté par fabb . Évalué à 2.
Je me suis profondément plongé dans le code source. Tâche grandement pénible.
J'ai bien vérifié et effectivement, tu as raison.
A mon grand désespoir. Pas le fait d'avoir tord fasse à toi (quoique :-)), mais je trouve abérant qu'on puisse écraser un fichier par une fichier différent sans le moindre warning ou option "--force". Cela ressemble à un workaround à la petit semaine.
> En fait, y'a un cas pour les updates, un autre quand tu fais une installe pure (-i).
En gros dans tous les cas :-)
> T'avais l'air pourtant à fond Red Hat, je ne comprends pas comment tu n'aies pas pu voir cela.
Moi non plus. Les bug report sur ce point sont "confidentiels".
J'ai fouillé rapidement mes archives de mailing Fedora et je n'ai pas trouvé de discussion sur ce point.
> Mais bon sang, l'exemple du gars qui n'a pas eu de réponse pour ce cas là, émettait l'hypothèse de savoir comment c'était géré dans Fedora pour "glib-devel" !
Désolé, je ne t'ai pas compris. Je croyais que tu me reprochais de ne pas avoir regardé "glib-devel" de Mandriva. Et comme je l'ai dit, ce paquet n'existe pas.
Je n'ignore pas que Fedora n'est pas la perfection en développement biarch, mon soucis était de savoir comme Mandriva fesait et compte-tenu de ma connaissance de Mandriva je ne comprenais pas.
> glib-devel dans Fedora c'est glib 1.2.10.
Oui. Mais je ne pensais pas que tu faisais une fixation sur la version 1.2. Il y a glib-devel et glib2-devel. J'ai regardé pour glib version 2 car c'est la version en cours. C'est tout.
> Dans Mandriva, tu vois pourtant un package libglib1.2-devel et lib64glib1.2-devel.
Très bien, mais je ne vais pas regarder pour une version de librairie bientôt obsolette.
> Ah ben si quand même, y'a que ceux là (+ un include) qui diffèrent, donc tu les sépares de sorte qu'une installation simultanée des 2 ne puisse conflicter.
Oui et non. Si les *-devel n'ont pas la même version-release (ce que tu envisageais) ce n'est pas suffisant. Je doute qu'il n'y ait de risque à mélanger glib-2.6.1 et glib-2.6.4.
Exemple :
- installation glib-devel-2.6.4 (x86_64) et glib-devel-2.6.1 (i386)
Dans ce cas, les /usr/include et autre /usr/share sont ceux de x86_64 (""grace"" à rpm).
Donc pour i386, tu compiles avec les entêtes 2.6.4 et fait l'édition de lien avec 2.6.1.
C'est pas très rigoureux/généric. Je ne jète pas la pierre à Mandriva.
Il faut que les librairies soient développer en conséquence (par exemple /usr/bin/glib-genmarshal ne doit faire que du arch-indépendant (ce qui est le cas)).
> Par ailleurs, le rpm x86_64 de Fedora/RH n'a aucune config 32-bit pour compiler (cf. les /usr/lib/rpm/i386-linux/macros & co).
Tout a fait. Il n'y a pas vraiment de support pour compiler du 32-bit sur amd64.
Faut installer gcc et les lib*-devel en i386.
Pour RHEL, c'est un poil différent car il y a une "infrastructure" pour compiler pour plusieurs versions de RHEL (RHEL 3 & 4 avec i386 et amd64, etc). Mais ça passe par un chroot et ce n'est pas le propos de ce thread. C'est beaucoup plus lourd.
Je n'ai jamais utilisé ça, c'est une sorte de concurrent de mach (que Red Hat n'a pas repris pour des bonnes raisons (sans remettre en cause mach) mais que j'ai oublié ; désolé).
> Je ne vois pas pourquoi tu sors ça.
OK, j'ai dit une connerie et pas qu'une.
Ça m'arrive. Mais trop de fois on a vu des "pro-Mandrake" promettre la lune alors qu'il n'y avait rien de nouveau. J'avais à tord dans ce thread un préjugé négatif et je m'en excuse. Maintenant je ne peux que reconnaitre que Mandriva a fait un travail intéressant et utile. Ce travail ne mérite pas mes commentaires précédents.
> Bon, tu ne veux pas télécharger et essayer par toi même?
Non. Mais ne t'inquiète pas, je le redis, Mandriva a fait du bon boulot et est allé au-delà de ce que fait RH/Fedora. Il me semble que j'ai maintenant compris ce qu'a fait Mandriva est les gains qu'on peut en tirer.
> Au fait, linux32 rpm --rebuild truc.rpm ne fonctionnera pas sous Fedora parce que tu aurais besoin en plus de spécificier CC="gcc -m32" et éventuellement CXX="g++ -m32".
Je n'étais pas dans cette optique. Je pensais à compilateur et *-devel en i386.
Effectivement, gcc de Mandriva est patché (gcc34-biarch-personality.patch).
> Mandrake n'a rien inventé
> Où ai-je dit que Mandrake a créé l'outil linux32? Bon sang, mais t'es terrible toi pour détourner les propos des gens. Le plus drôle (vraiment c'est comique là parce que tu es un spécimen) c'est que tu sors après tout un tas de patches, docs sur un truc insignifiant qui n'a rien à voir avec le propos initial. Juste avec un propos que tu as mal interprété ou bien détourné de sens encore une fois.
T'as raison de t'énervé, mais n'en profite pas trop :-)
# mandriva
Posté par Ramón Perez (site web personnel) . Évalué à 9.
# Encore une histoire de nom...
Posté par Janfi . Évalué à 10.
allez j'en lance un bien poilu...
parce que GNU, Hurd et Linux, ou encore Gentoo, Knoppix et consorts c'est plus fashion peut-être ?
De toute façon, ce nom a subit le test ultime : l'avis de ma femme. Or elle le trouve beaucoup mieux que l'ancien. Compte-tenu de la sous représentation du sexe faible dans les geeks pro-libre, on peut raisonnablement penser que ce public est de loin le plus porteur. Séduire les femmes c'est développer la base potentielle d'utilisatrices de logiciels libres.
Moralité : merci Mandrivasoft, grâce à ce changement, ma femme trouve mon PC plus sexy, je passe moins pour un con avec mes noms bizarres quand je parle de distributions linux et je suis redevenu quelqu'un de fréquentable pour mon entourage.
Tiens d'ailleurs ma femme m'appelle, j'ai oublié mes petits cachets...
[^] # Re: Encore une histoire de nom...
Posté par fabb . Évalué à -9.
Monbrake, pour mieux vous enculer. Toutes les femmes n'apprécient pas.
[^] # Re: Encore une histoire de nom...
Posté par liberforce (site web personnel) . Évalué à 5.
Perdu, c'est Mandriva tout court...
[^] # Re: Encore une histoire de nom...
Posté par yoyo7 . Évalué à 1.
ça fait quelques mois maintenant que j'utilise la mandrake 10.1 au quotidien et j'en suis tellement content que je n'ai pas éssayé d'autres distributions si ce n'est certaines live cd comme l'incontournable knoppix et linspire live cd qui devient intéressant je trouve.
Alors je vais faire comme pour la mandrake 10.1, je vais attendre qu'une âme charitable poste l'image iso en torrent quelque part. J' installerai la mandriva linux et je dirai encore que c'est un système génial de simplicité et de puissance !!!
Voilà bon vent à toutes et à tous et que la source soit avec vous !!! lol
[^] # Re: Encore une histoire de nom...
Posté par Raphaël G. (site web personnel) . Évalué à 0.
Quand on est pauvre (comme moi), on fait la chose suivante :
On va sur http://easyurpmi.zarb.org/(...) on séléctionne la version 2005
/!\ Attention y a pas les plf dedans, sans soute pas encore forké des plf-cooker), on sélectionne les mirroirs proxad pour les média contrib, main et jpackage
Je met pas le dernier (le java çapuecpaslibre, mais ça regarde que moi)
- ensuite on fait générer
dans une console root on tappe :
urpmi.removemedia -a
on copie colle les lignes générées, on attend
on fait :
urpmi urpmi
et un :
urpmi --auto-select
et préparez vous a attendre un moment que tout les paquets soient mis a jours...
ps : faut installer le nouveau kernel (urpmi kernel) et penser a remplacer les fichiers de conf par les .rpmnew, sauf pour /etc/passwd et /etc/group (et les fichiers de conf que vous avez modif a la main).
Avec ça on évite de polluer la planète avec des cd gravés, bon pour les frilleux, graver l'iso 1, pour le mode rescue et réinstaller en cas derreur/crash disk/etc...
# re
Posté par Sylvain (site web personnel) . Évalué à 1.
[^] # Re: re
Posté par Anonyme . Évalué à 2.
# Téléchargement en cours...
Posté par DrahcirBS . Évalué à 1.
[^] # Re: Téléchargement en cours...
Posté par Gael Beaudoin (site web personnel) . Évalué à 1.
[^] # Re: Téléchargement en cours...
Posté par FRLinux (site web personnel) . Évalué à 3.
Pour ceux faisant du NAT avec pare-feu, il existe assez de pages expliquant les ports a ouvrir ...
Chez moi ca donne :
file: Mandriva-Linux-2005-Limited-Edition-DVD.i586
size: 4,675,205,766 (4.4 GB)
dest: Mandriva-Linux-2005-Limited-Edition-DVD.i586.iso
status: finishing in 1:08:06 (79.2%)
speed: 133.9 KB/s down - 269.1 KB/s up
totals: 3.5 GB down - 6.1 GB up
Steph
[^] # Re: Téléchargement en cours...
Posté par eon2004 . Évalué à 6.
[^] # Re: Téléchargement en cours...
Posté par soulflyb (Mastodon) . Évalué à 3.
mandriva est arrivée ce matin, je l'installe cet aprèm et je vous fait un petit rapport
mais attention : je suis un habitué de mandrake (ca fait 6 ans que je j'utilise mandrake et je n'ai jamais changé malgré de nombreux tests d'autres distros), donc cela risque d'être un peu biaisé ;)
[^] # Re: Téléchargement en cours...
Posté par DrahcirBS . Évalué à 1.
# meuh
Posté par gc (site web personnel) . Évalué à 4.
C'est un rien méprisant ça..
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.