Misc a écrit 6329 commentaires

> 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.

> le NTFS c de la merde

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 )

Cooker evolue plus.

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 )

http://plf.zarb.org/(...)

( et rappelez, utilisez le p2p de façon responsable, comme tout les outils )

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...

> Tous les développements de MandrakeSoft sont distribués sous licence
> 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...

> il manque un urpm-setup

urpmi.setup, dispo sur les cd depuis la 9.2 dans main, et sur les miroirs ftp depuis la 9.1.

Ç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...

Sauf que tu regarde les 2 premiers post du journal, c'est à base de "upgrade en sid, jamais eu de merde, trop bien".

Donc faudrait savoir.

Le mélange des compilés et compilables, j'ai tenté sur netbsd, j'ai vite plus trop eu le choix et j'ai du passer en package compilé via pkgsrc...

Remarque, vu que dpkg c'est juste des fichiers installable via ar et gunzip, ça sert vraiment à rien :)

( et rpm aussi, il y a meme un script rpm2cpio en perl sur netbsd qui fait ça )

Dans la FAQ debian :

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.

> 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.

> Mdk, j'ai eu des prob aussi avec. Car les outils de configuration
> 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.

> Tu es serieux ? Parce que la ta credibilite vient d'en prendre un coup.
>
> 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.

> Pour Gimp, la version 2.0 est déjà en sid, mais je sait pas si elle est en
> testing. Je sait pas si elle aura le temps de passer en testing avant le gel
> de celle-ci pour la sortie de la Sarge...

Trop gros, passera pas
On a déja fait le coup pour gnome2.4 l'année dernière...

> Et telecharger des ISOs, avec Debian, Gentoo ou encore *BSD on le fait
> une seule fois et on peut vivre des annees avec un systeme a jour en
> permanence sans maj brutale

Bah j'ai une machine sur mdk 9.1 que j'ai mis à jour depuis la 8.2, sans passer par cooker et sans prendre les isos. J'ai pas plus mis à jour parce que j'ai pas le temps de le faire sur ma pauvre ligne adsl, à 500 Km de distance de mon logement actuel, mais ça passe.

Faut arréter de croire qu'on est "obligé" de passer par les isos, et que seuls les distributions qui ne sont pas destinés au grand public offrent ça.

C'est quand même incroyable cette idée de se convaincre de la supériorité d'un systéme plus dur à installer en se disant qu'on est récompensé de notre perséverance par le fait de pouvoir faire une mise à jour sans les cds...

Et puis tu parle de mises à jours incrémentals et debian, mais si l'incrément, c'est moins que tout les 2 ans, c'est que tu utilise une unstable/testing, et c'est des versions de développement...
Donc, autant pour gentoo et bsd, ok, autant pour debian on me le fera pas gober.

> En general, un rm /* c'est jamais bon, quelque soit le systeme de package.

Sur windows, ça me fait :
rm command not found

Donc windows rox

=>[]

Si, justement.
Si tu veut utiliser cooker, prends tout cooker.