> Ce qui rend NTFS "nul" c'est surtout que son fonctionnement est classé
> secret-défense chez Microsoft et que malheureusement le driver
> disponible en open-source ne fonctionne pas encore très bien en écriture.
> Par conséquent, difficile d'exploiter un disque dur formaté en NTFS sous
> linux.
Il est pas calssé secret defense, il est juste trés compliqué et il faut du temps. NTFS est relativement documenté, comme le dit l'auteur de ntfsresize :
Non, ça n'a rien à voir.
Un paquet en cooker ne deviendra pas automatiquement un paquet de community, c'est un acte volontaire que d'uploader un backport dans la community.
Au contraire de testing qui se remplit via unstable.
Ça n'a donc rien à voir. Si tu veut un exemple plus parlant, official, c'est la "woody", community, ça serais "woody" + backport.org, mais moins suivi sur le nombre de backport ( car il y a moins besoin et moins de ressources ), et cooker resterais toujours "experimental" + "unstable".
Pour ce qui est des upload en community, c'est surtout les bugfixes qu'on uploadera, sauf si le mainteneur veut faire un backport ( ce qui prends du temps ).
J'ai pas dit que je connaissais mieux, justement.
Ma remarque, c'était juste pour expliquer pourquoi il fallait de toute façon casser tout les miroirs. Ils ont pas fait ça par plaisir ou par erreur, mais plus par obligation.
> Ils auraient pu tout de même avoir la décence d'attendre que la situation
> des miroirs se soit stabilisée...
Le temps que tu finisse de récuperer les cds, les miroirs seront stabilisés. Free remarche déja, urpmi.org liste déja trois miroirs à jours.
Et il y en aura plus demain.
> Mais bon, un problème après l'autre, faisons d'abord rentrer le fric et
> tentons ensuite de résoudre les problèmes, ça a bien réussi à une firme
> de Redmond !
En quoi ça fait rentrer plus de fric ?
Mandrake a fait ce qu'ils ont du, à savoir chang éle miroir principal, et voir si la synchronisation se passe bien. Ensuite, les miroris secondaires, ç'est plus de leur domaine, ils ont aucun pouvoir sur eux.
Alors, oui tu te fait moinssé.
Maintenant, quand on fait des attaques non fondés, on assume.
Ça vallait même pas un point pour un joli lancer de troll, ça vaut rien.
> Ne pas avoir les serveurs de base dans la Power Pack, c'est pas terrible
> non plus.
Dans les listes que j'ai, j'ai ça :
home/misc $ grep proftpd-1 10.0-cty.cd | grep Power
10.0-Community-Powerpack-2 673465 proftpd-1.2.9-3mdk.i586
/home/misc $ grep apache2-2 10.0-cty.cd | grep Power
10.0-Community-Powerpack-1 1774296 apache2-2.0.48-5mdk.i586
/home/misc $ grep postfix-2.1 10.0-cty.cd | grep Power
10.0-Community-Powerpack-1 1121190 postfix-2.1.0-0.20040209.18mdk.i586
C'etait pour la community, j'ai vite pris les 3 premiers serveurs de bases auquel j'ai pensé.
Tu as effectivement du boire pour ne pas les voir.
Enfin ça depend aussi de ce que tu appelle de base...
> par contre ne pas mettre Mozilla,
Moi, ça me semble logique de mettre konqueror dans un bureau kde, car il est intégré et prends moins de place par rapport à mozilla sur le cd, car il partage les libs.
Ntfs gére les permissions, avec ACL, gére des noms plus longs, des plus gros volumes. Et il y a surement aussi des index et autres joyeusetés comme ça, que fat n'a pas. Et il est aussi journalisé.
C'est pas parce que tu n'arrive pas à écrire sous linux que c'est forcément de la merde.
Il vaudrait mieux que tu reflechisse au lieu de dire et faire des conneries comme celle qui a donné lieu à ça : http://archives.mandrakelinux.com/cooker/2004-04/msg01274.php(...)
"I hope all debianist (paranoïac license defensor) would be satisfied..."
parce que quelqu'un t'a demandé de ne pas dire que le kernel avec les modules nvidias est sous gpl.
Ouais, mais tu voit, ça fait quand meme ~ 40 go de données à retélecharger ( taille du repertoire 9.1 + 9.2 + 10.0 ).
Et la je compte pas les isos ( mdk + move ) ni la cooker, ni les vielles distribs ( 120 Go au total ).
C'est pas vraiment ce que j'appelle gérer les déplacements que de retelecharger tout....
Il y a surtout eu le besoin de changer Mandrake Linux en Mandrakelinux comme nom racine sur les ftp, suite à certains evenements.
La réorganisation des miroirs a été fait dans la foulée, vu qu'il fallait de toute façon tout resynchronisé ( rsync ne gérant pas les déplacements/renommages de fichiers )
Community, c'est pour recevoir quelque backport, tel que j'ai compris.
Genre gnomemeeting qui est sorti en version 1.0 que tout le monde réclame à corps et à cris ( note : réclamer ne ménera à rien si tout le monde le fait )
Ils ont aussi profités du changement de noms ( Mandrake Linux => Mandrakelinux ) qui a forcé à déplacer le dossier racine, et donc, forcément, devait péter les miroirs ( et oui, rsync ne gére pas les déplacements et copie de fichier ).
La question n'est pas de savoir ce qui est utilisé pour installer les paquets, mais plutot les paquets qui sont à installer.
Si jamais le packageur de X le compile sur une machine ou il faut tel version de tel lib, que tu utilise apt, yum, emerge ou ce que tu veut, il te faut la version de la lib, point barre.
C'est pas comme windows ou on a des binaires qui ne partage aucun code, ou qui depende sur des bibliothéques qui ont la compatiblités avec des trucs durant des années.
Que ça soit bien ou pas, je vous laisse en juger, mais au moins, le libre avance plus vite, en parti grace et à cause de ça.
> L'idéal serait à mon avi: un installeur à la redhat, une base de logiciel et
> qualité des outils comme ceux de debian et des logiciels à jour comme
> pour la gentoo... (c'est très superficiel ce que je dis et demanderait plus
> de réflexion...:))
Des outils à la fois trés à jour, mais avec des mois de tests, oui brillant.
Pourquoi ne pas avoir pensé plus tot...
Ça fait 2 ans que je suis en cooker sans réinstaller, comme toi en unstable , et ça fait 2 ans que j'ai pas formaté mon poste de travail en 9.1, qui était à la base en 8.2, que j'ai mis à jour en live...
Mais bon faut aussi dire que j'ai jamais réinstallé non plus windows 95, je doit avoir du pot...
Mais tu as raison, debian c'est tellement mieux...
http://www.debian.org/devel/testing(...)
"Les simples utilisateurs et les développeurs de testing doivent savoir que les mises à jour de sécurité pour testing ne sont pas gérées par l'équipe chargée de la sécurité".
> Sur bon nombres d'applications, en supprimant ce qui ne nous sert pas,
> peut on vraiment arriver à un gain de temps conséquent ? A tu des
> exemples ?
En l'occurence, j'ai terminé par le fait que le binaire suffit, je ne suis pas plus convaincu que toi sur les gains en question, car ils sont anéantis par le fait que tu as besoin des entêtes de tes libs. Par exemple, qt, ça prends quand meme ~ 80Mo
J'ai une gentoo avec juste plone et deux trois softs annexes qui prennent 1go de place sur un chroot. 1go , il y a de quoi placer X et icewm plus de quoi travailler sur une mdk ou une debian. Et j'ai pas mis des optimisations de fou, j'ai mis en -Os justement pour ça.
Donc, non j'ai pas d'exemple :)
> Sans parler que pour moi il est inconcevable de mettre en production un
> serveur disposant d'un envirronement de compilation.
Bof. Une fois qu'on est root dessus, si le truc c'est juste de faire un yum install gcc, ça me semble pas être trés dure à contourner comme protection...
Sans compter que les languages de script, ça permet beaucoup aussi ( bon oui, on fait pas de modules kernels en python ou perl :) )
> Tu joue sur les mots entre mettre à jour sa distrib et ses logiciels. Bon, si
> tu veux, mais mon problème reste le même. Comment sur une mdk 9.1
> installer tous les derniers logiciels stables comme gimp2 et gnome 2.6 en
> gardant l'utilité des rpms ?
Tu m'arrete ou j'ai mal compris, mais :
Tu veut mettre tout les paquets de gnome2.6 sur la 9.1.
Ok.
Quitte à faire pareil, on va faire suivre kde, ok, pour ceux qui veulent kde.
Bon.
Et puis, il y a surement des paquets qui vont dépendre sur python plus récent, on va mettre python. Et tout les softs qui dependent de python aussi. De toute façon tu as dit : "installer tous les derniers logiciels stables".
En bref, remettre à jour _tout_ les rpms, sur la 9.1, parce que en plus quelqu'un voudra surement un paquet plus à jour de tel soft. On va pas faire de jaloux, hein, parce que sinon, on a autant ne rien faire si on doit exclure certaines personnes, ça serait pas très égalitaire.
Mais euh, attends. C'est plus une 9.1, c'est une 9.2 ou 10 que tu va avoir si tu mets à jours tout les rpms.
Damn. Et oui, voila le truc.
SI tu veut , tu peut te refaire des backports. Si tu veut, tu peut même lancer un projet pour les redistribuer.
Je suis sur qu'en demandant à des groupes annexes à mdk ( en 3 lettres ) et en offrant ta bonne volonté et en ayant des idées et surtout de la bonne volontés, et que tu la mets en oeuvre, tu peut avoir un compte sur un serveur pour commencer à bosser et à chercher d'autres personnes pour t'aider.
Pour ma part, je trouve que les backports ne sont que sources de problémes, mais bon si tu arrive à prouver le contraire, je changerais d'avis.
Il y a l'optimisation dans le mesure ou tu as pas des trucs inutiles, comme le support perl alors que tu veut pas de perl.
Prenons un exemple simple :
Soit A le paquet binaire, compilé avec des options
Soit toi, qui veut compiler soit via une option 1 qui réduit la taille ( -Os ) ou via des optimisations en plus ( -O2 ) ( option 2 ).
Il y a des différences dans les 2 approches. Le paquet bianire de A ne peut pas prendre les deux options, car on peut pas à la fois le code le plus rapide et le plus compacte ( exemple, le fait de dérouler les boucles ).
Donc, si A privilégie la taille, alors compiler via l'option 2 sera plus proche de ce qu'on veut si on veut les optimisations et donc plus proche du paquet optimum.
Et inversement, si le paquet binaire privilégie les optims de gcc, on aura notre binaire compilé par nos mimines plus proche de ce qu'on veut si on veut avoir des binaires plus petits qui chargent plus vite, et prennent moins de ram.
Conclusion, les sources, ça permet d'avoir ce qu'on veut. Et je parle pas encore d'avoir ce qu'on veut au niveau des dépendances.
Maintenant, c'est vrai que compiler au dela de i586 tout les programmes, ça donne pas des masses de gains sauf si le soft est prévu pour, via des instructions en assembleurs, et la plupart des paquets binaires suffisent très largement.
Depuis quand une recherche sur google devient un argument ?
> Tout depend de la DB, mais ceci n'est qu'un probleme parmi tant d'autres.
> Utiliser une DB pour gerer la base du systeme, ca me parait
> dangereusement complique. Peut-on installer une distrib RPM sans la DB ?
Non. Maintenant, les db, ça sert à plein de choses. Tu doit sans doute savoir que ta banque utilise une db pour tes comptes, ça me semble bien plus dangereux pour toi que ton argent depende d'une base de données, plutot que la liste des softs de ton pc.
[^] # Re: Quid de la stabilité ?
Posté par Misc (site web personnel) . En réponse à la dépêche Mandrakelinux 10.0 Official est arrivée !. Évalué à 5.
> secret-défense chez Microsoft et que malheureusement le driver
> disponible en open-source ne fonctionne pas encore très bien en écriture.
> Par conséquent, difficile d'exploiter un disque dur formaté en NTFS sous
> linux.
Il est pas calssé secret defense, il est juste trés compliqué et il faut du temps. NTFS est relativement documenté, comme le dit l'auteur de ntfsresize :
http://archives.mandrakelinux.com/cooker/2003-08/msg02534.php(...)
Faut arreter les délires sur Microsoft qui chercherais à ralentir la concurence, tout en continuant à dire que fat ça pue, ça gére rien.
[^] # Re: Mandrakelinux 10.0 Official est arrivée !
Posté par Misc (site web personnel) . En réponse à la dépêche Mandrakelinux 10.0 Official est arrivée !. Évalué à 3.
Un paquet en cooker ne deviendra pas automatiquement un paquet de community, c'est un acte volontaire que d'uploader un backport dans la community.
Au contraire de testing qui se remplit via unstable.
Ça n'a donc rien à voir. Si tu veut un exemple plus parlant, official, c'est la "woody", community, ça serais "woody" + backport.org, mais moins suivi sur le nombre de backport ( car il y a moins besoin et moins de ressources ), et cooker resterais toujours "experimental" + "unstable".
Pour ce qui est des upload en community, c'est surtout les bugfixes qu'on uploadera, sauf si le mainteneur veut faire un backport ( ce qui prends du temps ).
[^] # Re: Mandrakelinux 10.0 Official est arrivée !
Posté par Misc (site web personnel) . En réponse à la dépêche Mandrakelinux 10.0 Official est arrivée !. Évalué à 1.
Ma remarque, c'était juste pour expliquer pourquoi il fallait de toute façon casser tout les miroirs. Ils ont pas fait ça par plaisir ou par erreur, mais plus par obligation.
[^] # Re: Mandrakelinux 10.0 Official est arrivée !
Posté par Misc (site web personnel) . En réponse à la dépêche Mandrakelinux 10.0 Official est arrivée !. Évalué à 1.
> des miroirs se soit stabilisée...
Le temps que tu finisse de récuperer les cds, les miroirs seront stabilisés. Free remarche déja, urpmi.org liste déja trois miroirs à jours.
Et il y en aura plus demain.
> Mais bon, un problème après l'autre, faisons d'abord rentrer le fric et
> tentons ensuite de résoudre les problèmes, ça a bien réussi à une firme
> de Redmond !
En quoi ça fait rentrer plus de fric ?
Mandrake a fait ce qu'ils ont du, à savoir chang éle miroir principal, et voir si la synchronisation se passe bien. Ensuite, les miroris secondaires, ç'est plus de leur domaine, ils ont aucun pouvoir sur eux.
Alors, oui tu te fait moinssé.
Maintenant, quand on fait des attaques non fondés, on assume.
Ça vallait même pas un point pour un joli lancer de troll, ça vaut rien.
[^] # Re: Mandrakelinux 10.0 Official est arrivée !
Posté par Misc (site web personnel) . En réponse à la dépêche Mandrakelinux 10.0 Official est arrivée !. Évalué à 3.
> non plus.
Dans les listes que j'ai, j'ai ça :
home/misc $ grep proftpd-1 10.0-cty.cd | grep Power
10.0-Community-Powerpack-2 673465 proftpd-1.2.9-3mdk.i586
/home/misc $ grep apache2-2 10.0-cty.cd | grep Power
10.0-Community-Powerpack-1 1774296 apache2-2.0.48-5mdk.i586
/home/misc $ grep postfix-2.1 10.0-cty.cd | grep Power
10.0-Community-Powerpack-1 1121190 postfix-2.1.0-0.20040209.18mdk.i586
C'etait pour la community, j'ai vite pris les 3 premiers serveurs de bases auquel j'ai pensé.
Tu as effectivement du boire pour ne pas les voir.
Enfin ça depend aussi de ce que tu appelle de base...
> par contre ne pas mettre Mozilla,
Moi, ça me semble logique de mettre konqueror dans un bureau kde, car il est intégré et prends moins de place par rapport à mozilla sur le cd, car il partage les libs.
[^] # Re: Quid de la stabilité ?
Posté par Misc (site web personnel) . En réponse à la dépêche Mandrakelinux 10.0 Official est arrivée !. Évalué à 3.
Ntfs gére les permissions, avec ACL, gére des noms plus longs, des plus gros volumes. Et il y a surement aussi des index et autres joyeusetés comme ça, que fat n'a pas. Et il est aussi journalisé.
C'est pas parce que tu n'arrive pas à écrire sous linux que c'est forcément de la merde.
Il vaudrait mieux que tu reflechisse au lieu de dire et faire des conneries comme celle qui a donné lieu à ça :
http://archives.mandrakelinux.com/cooker/2004-04/msg01274.php(...)
"I hope all debianist (paranoïac license defensor) would be satisfied..."
parce que quelqu'un t'a demandé de ne pas dire que le kernel avec les modules nvidias est sous gpl.
[^] # Re: Mandrakelinux 10.0 Official est arrivée !
Posté par Misc (site web personnel) . En réponse à la dépêche Mandrakelinux 10.0 Official est arrivée !. Évalué à 7.
Et la je compte pas les isos ( mdk + move ) ni la cooker, ni les vielles distribs ( 120 Go au total ).
C'est pas vraiment ce que j'appelle gérer les déplacements que de retelecharger tout....
[^] # Re: Mandrakelinux 10.0 Official est arrivée !
Posté par Misc (site web personnel) . En réponse à la dépêche Mandrakelinux 10.0 Official est arrivée !. Évalué à 2.
La réorganisation des miroirs a été fait dans la foulée, vu qu'il fallait de toute façon tout resynchronisé ( rsync ne gérant pas les déplacements/renommages de fichiers )
[^] # Re: Mandrakelinux 10.0 Official est arrivée !
Posté par Misc (site web personnel) . En réponse à la dépêche Mandrakelinux 10.0 Official est arrivée !. Évalué à 1.
Community, c'est pour recevoir quelque backport, tel que j'ai compris.
Genre gnomemeeting qui est sorti en version 1.0 que tout le monde réclame à corps et à cris ( note : réclamer ne ménera à rien si tout le monde le fait )
[^] # Re: Mldonkey stable
Posté par Misc (site web personnel) . En réponse au journal Mldonkey stable. Évalué à 1.
( et rappelez, utilisez le p2p de façon responsable, comme tout les outils )
[^] # Re: Pour la mandrake 10, les miroirs qui marchent ... (juste 2 en fait :) )
Posté par Misc (site web personnel) . En réponse au journal Pour la mandrake 10, les miroirs qui marchent ... (juste 2 en fait :) ). Évalué à 1.
[^] # Re: Docker 0.14, un gestionnaire de paquets pour Windows
Posté par Misc (site web personnel) . En réponse à la dépêche Docker 0.14, un gestionnaire de paquets pour Windows. Évalué à 1.
Si jamais le packageur de X le compile sur une machine ou il faut tel version de tel lib, que tu utilise apt, yum, emerge ou ce que tu veut, il te faut la version de la lib, point barre.
C'est pas comme windows ou on a des binaires qui ne partage aucun code, ou qui depende sur des bibliothéques qui ont la compatiblités avec des trucs durant des années.
Que ça soit bien ou pas, je vous laisse en juger, mais au moins, le libre avance plus vite, en parti grace et à cause de ça.
[^] # Re: coup de gueule du soir
Posté par Misc (site web personnel) . En réponse au journal coup de gueule du soir. Évalué à 1.
> qualité des outils comme ceux de debian et des logiciels à jour comme
> pour la gentoo... (c'est très superficiel ce que je dis et demanderait plus
> de réflexion...:))
Des outils à la fois trés à jour, mais avec des mois de tests, oui brillant.
Pourquoi ne pas avoir pensé plus tot...
[^] # Re: Tu es visiblement mal informé !
Posté par Misc (site web personnel) . En réponse au journal coup de gueule du soir. Évalué à 1.
> GPL. Le code source est disponible dans les SRPM présents sur les miroirs.
Et sur le cvs ( cvs.mandrakesoft.com )
> J'ai l'impression que depuis l'apparition d'URPMI
qui remonte quand meme à quelque années, pour souligner la fraicheur du troll...
[^] # Re: coup de gueule du soir
Posté par Misc (site web personnel) . En réponse au journal coup de gueule du soir. Évalué à 1.
urpmi.setup, dispo sur les cd depuis la 9.2 dans main, et sur les miroirs ftp depuis la 9.1.
[^] # Re: Tu es visiblement mal informé !
Posté par Misc (site web personnel) . En réponse au journal coup de gueule du soir. Évalué à 1.
Mais bon faut aussi dire que j'ai jamais réinstallé non plus windows 95, je doit avoir du pot...
Mais tu as raison, debian c'est tellement mieux...
[^] # Re: éternel dilemne
Posté par Misc (site web personnel) . En réponse au journal éternel dilemne. Évalué à 1.
Donc faudrait savoir.
[^] # Re: éternel dilemne
Posté par Misc (site web personnel) . En réponse au journal éternel dilemne. Évalué à 1.
[^] # Re: éternel dilemne
Posté par Misc (site web personnel) . En réponse au journal éternel dilemne. Évalué à 1.
( et rpm aussi, il y a meme un script rpm2cpio en perl sur netbsd qui fait ça )
[^] # Re: éternel dilemne
Posté par Misc (site web personnel) . En réponse au journal éternel dilemne. Évalué à 1.
http://www.debian.org/devel/testing(...)
"Les simples utilisateurs et les développeurs de testing doivent savoir que les mises à jour de sécurité pour testing ne sont pas gérées par l'équipe chargée de la sécurité".
Maintenant, c'est un risque à prendre.
[^] # Re: éternel dilemne
Posté par Misc (site web personnel) . En réponse au journal éternel dilemne. Évalué à 1.
> peut on vraiment arriver à un gain de temps conséquent ? A tu des
> exemples ?
En l'occurence, j'ai terminé par le fait que le binaire suffit, je ne suis pas plus convaincu que toi sur les gains en question, car ils sont anéantis par le fait que tu as besoin des entêtes de tes libs. Par exemple, qt, ça prends quand meme ~ 80Mo
J'ai une gentoo avec juste plone et deux trois softs annexes qui prennent 1go de place sur un chroot. 1go , il y a de quoi placer X et icewm plus de quoi travailler sur une mdk ou une debian. Et j'ai pas mis des optimisations de fou, j'ai mis en -Os justement pour ça.
Donc, non j'ai pas d'exemple :)
> Sans parler que pour moi il est inconcevable de mettre en production un
> serveur disposant d'un envirronement de compilation.
Bof. Une fois qu'on est root dessus, si le truc c'est juste de faire un yum install gcc, ça me semble pas être trés dure à contourner comme protection...
Sans compter que les languages de script, ça permet beaucoup aussi ( bon oui, on fait pas de modules kernels en python ou perl :) )
[^] # Re: éternel dilemne
Posté par Misc (site web personnel) . En réponse au journal éternel dilemne. Évalué à 1.
> tu veux, mais mon problème reste le même. Comment sur une mdk 9.1
> installer tous les derniers logiciels stables comme gimp2 et gnome 2.6 en
> gardant l'utilité des rpms ?
Tu m'arrete ou j'ai mal compris, mais :
Tu veut mettre tout les paquets de gnome2.6 sur la 9.1.
Ok.
Quitte à faire pareil, on va faire suivre kde, ok, pour ceux qui veulent kde.
Bon.
Et puis, il y a surement des paquets qui vont dépendre sur python plus récent, on va mettre python. Et tout les softs qui dependent de python aussi. De toute façon tu as dit : "installer tous les derniers logiciels stables".
En bref, remettre à jour _tout_ les rpms, sur la 9.1, parce que en plus quelqu'un voudra surement un paquet plus à jour de tel soft. On va pas faire de jaloux, hein, parce que sinon, on a autant ne rien faire si on doit exclure certaines personnes, ça serait pas très égalitaire.
Mais euh, attends. C'est plus une 9.1, c'est une 9.2 ou 10 que tu va avoir si tu mets à jours tout les rpms.
Damn. Et oui, voila le truc.
SI tu veut , tu peut te refaire des backports. Si tu veut, tu peut même lancer un projet pour les redistribuer.
Je suis sur qu'en demandant à des groupes annexes à mdk ( en 3 lettres ) et en offrant ta bonne volonté et en ayant des idées et surtout de la bonne volontés, et que tu la mets en oeuvre, tu peut avoir un compte sur un serveur pour commencer à bosser et à chercher d'autres personnes pour t'aider.
Pour ma part, je trouve que les backports ne sont que sources de problémes, mais bon si tu arrive à prouver le contraire, je changerais d'avis.
[^] # Re: éternel dilemne
Posté par Misc (site web personnel) . En réponse au journal éternel dilemne. Évalué à 1.
Prenons un exemple simple :
Soit A le paquet binaire, compilé avec des options
Soit toi, qui veut compiler soit via une option 1 qui réduit la taille ( -Os ) ou via des optimisations en plus ( -O2 ) ( option 2 ).
Il y a des différences dans les 2 approches. Le paquet bianire de A ne peut pas prendre les deux options, car on peut pas à la fois le code le plus rapide et le plus compacte ( exemple, le fait de dérouler les boucles ).
Donc, si A privilégie la taille, alors compiler via l'option 2 sera plus proche de ce qu'on veut si on veut les optimisations et donc plus proche du paquet optimum.
Et inversement, si le paquet binaire privilégie les optims de gcc, on aura notre binaire compilé par nos mimines plus proche de ce qu'on veut si on veut avoir des binaires plus petits qui chargent plus vite, et prennent moins de ram.
Conclusion, les sources, ça permet d'avoir ce qu'on veut. Et je parle pas encore d'avoir ce qu'on veut au niveau des dépendances.
Maintenant, c'est vrai que compiler au dela de i586 tout les programmes, ça donne pas des masses de gains sauf si le soft est prévu pour, via des instructions en assembleurs, et la plupart des paquets binaires suffisent très largement.
[^] # Re: éternel dilemne
Posté par Misc (site web personnel) . En réponse au journal éternel dilemne. Évalué à 0.
> sympatoche à trop vouloir configuer font que mon pc s'épuise.
Les outils se lancent pas tout seul sauf erreur de ma part.
> suse, j'ai peur qu'en installant un suse, j'ai le droit à de superbes menus
> en allemand...
Euh, c'est pas conectiva non plus, la suse est au moins traduite en anglais, et en francais.
[^] # Re: éternel dilemne
Posté par Misc (site web personnel) . En réponse au journal éternel dilemne. Évalué à 2.
>
> http://www.google.com/search?q=rpm+corruption(...(...))
Depuis quand une recherche sur google devient un argument ?
> Tout depend de la DB, mais ceci n'est qu'un probleme parmi tant d'autres.
> Utiliser une DB pour gerer la base du systeme, ca me parait
> dangereusement complique. Peut-on installer une distrib RPM sans la DB ?
Non. Maintenant, les db, ça sert à plein de choses. Tu doit sans doute savoir que ta banque utilise une db pour tes comptes, ça me semble bien plus dangereux pour toi que ton argent depende d'une base de données, plutot que la liste des softs de ton pc.