On Fri, Jun 20, 2003 at 10:22:08AM +0200, Thomas Nemeth wrote: > Le 20.06.03, Sven Luther a tapot� : > > | On Thu, Jun 19, 2003 at 09:00:06PM +0200, Thomas Nemeth wrote: > | > | > | > | Oui et non, si c'est pas convivial, les utilisateurs vont encore rale. > | > > | > Je n'ai pas dit le contraire, hein :) Mais permettre d'avoir des > | > types d'interfaces diff�rentes est un atout majeur. Et les > | > interfaces texte rapides et efficaces sont la panac�es pour les > | > "vieux de la vieille" qui comme moi aiment bien installer leurs > | > trucs en 2 temps 3 mouvements... > | > | Sur, sur. Mais rien ne t'empeche de te faire un petit script. Je pense > | que tu doit meme pouvoir appeller busybox et d'autre trucs du genre, > | apres tout, la seule chose que tu fait, c'est court circuiter le systeme > | de menu actuel. > | > | Mmm, maintenant que j'y pense, cela pourrait etre une maniere sympa > | d'automatiser des installs. Peut etre pourrait-on (pourais-tu ?) ajouter > | du code a debian-installer pour creer un script a partir d'une premiere > | install, et pouvoir ensuite le reutiliser pour faire plusieurs install > | du meme genre ? Un peu comme certains logiciel te permettent de faire > | des macros ? > > Ce serait int�ressant � avoir effectivement. Si tant est qu'on > puisse choisir ce type d'install au boot...
Si quelqu'un s'en charge, il y a pas de raisons que cela ne soit pas present, un quick install ou un truc du genre. Il faut juste que quelqu'un le fasse. > | > Plus r�cent comme matos : je bosse actuellement sur une SS20 qui > | > n'a que 2 disques de 1Go chacun avec un sarge. J'avais install� > | > | Largement suffisant, je pense que la limite se situe aux alentours de > | 800Mo. > > ulie[~] df -h > Sys. de fich. Tail. Occ. Disp. %Occ. Mont� sur > /dev/sda1 124M 18M 100M 16% / > /dev/sda4 49M 17K 46M 1% /tmp > /dev/sda5 291M 66M 210M 24% /var > /dev/sdb1 987M 599M 338M 64% /usr > /dev/sda6 349M 63M 268M 19% /usr/local > druuna:/home 2,0G 556M 1,3G 30% /home > druuna:/var/mail 99M 206K 94M 1% /var/mail > > Comme tu le vois /usr qui fait pr�s d'1Go est plein au 2/3 > ce qui est la limite acceptable pour pouvoir travailler... Pourquoi ? Une fois installe, tu ne devrait plus avoir a toucher a /usr, et donc /usr peut etre entierement plein, meme ro d'ailleurs. > | > Je te raconte pas la frayeur 18 Mo d'un coup, sans parler des > | > python en double... Du coup, j'ai tout vir� :) > | > | Oui, mais cela c'est ce qui arrive si on suit testing, cela ne te > | serrait pas arrive si tu avait utilise woody. C'est le probleme de la > > Woody est un chouya � la bourre pour ce que j'avais besoin de > faire... M�me testing est limite. Mais j'avoue que sur les 3/4 > de mes autres machines j'en suis encore � potato ;) Qui est encore supporte en securite grace au travail de la securite team. > | poule et de l'oeuf. Certains disent qu'il faudrait que les DD utilisent > | stables exclusivement, mais c'est aussi les memes qui ralent lorsque la > | release suivante de debian est trop lente a venir. Et tu n'avait pas > | python en double, le package python est juste un wrapper presque vide > | qui depend de python2.2. Tout comme gcc est un wrapper presque vide qui > > Je sais. Si je dis que je l'avais en double c'est parcequ'il > y a d�j� python 2.1 d'install�... :))) > | depend de gcc-3.3 actuellement. C'est le mechanisme qui marche le mieux > | pour faire des upgrades de versions transparente pour la majeure partie > | des utilisateurs, tout en permettant d'avoir des versions differentes > | installe simultanement. > > Et qui emp�che de compiler correctement le noyau ;) Non, que avec les anciens noyaux, et c'est la faute aux noyaux de toute facon. le package 2.4.20-8 compile bien avec gcc 3.3, et les noyaux 2.4.21 upstream aussi. Et si vraiment tu a besoin d'un noyau plus ancien, il te suffit d'utiliser gcc 3.2 pour cela. > | > | > Au mieux j'essaye de faire r�fl�chir sur un probl�me particulier > | > | > qui me pose probl�me. Apr�s, comme je le dis, chacun est libre > | > | > d'en faire ce qu'il veut, un mv vers /dev/null y compris ;) > | > | > | > | Mais qui est le plus competent pour regler ces problemes, sur les DD ont > | > | leur importance, mais dans le logiciel libre, celui qui sa demange le > | > | plus est aussi celui le plus adapte pour resoudre le probleme. > | > > | > Oui. > | > | Donc on est d'accord, les plus competent pour resoudre un probleme, > | c'est souvent ceux qui ralent le plus, mais qui ont trop la fleme pour > | le faire eux meme (la je suis peut etre trop agressif, il y a surement > | des tas de bonne raisons pour ne pas mettre la mains a la pate). > > En fait, on n'est pas tout � fait d'accord : ceux qui trouvent > un probl�me ou pense qu'il y en a 1 sont ceux qui sont le plus > � m�me d'en discuter avec ceux qui ont les moyens et les > connaissances pour le r�soudre. N'importe qui peut tomber sur > un truc g�nant sans pour autant �tre programmeur et dans ce cas > �a n'aidera pas � le r�soudre sauf � force de discussions avec > ceux qui le peuvent... Oui, mais pas besoin de passer par un echelon intermediaire (les DD qui suivent d-u-f). > | > | Oui, mais cela demande quand meme que l'on s'investisse pour comprendre > | > | le probleme, puis qu'on le resume, qu'on passe le temps necessaire pour > | > | ecrire dans la mailing liste concerne, qu'on se prene les flammes a la > | > | place de la personne interesse, etc ... > | > > | > Je crois que c'est surtout ce dernier point qui emp�che ;) Surtout > | > si c'est pas l'id�e du type qui poste dans la ml DD... > | > | Oui, mais quand meme, il faut y penser, ecrire le poste, rediriger la > | reponse vers les bonne personnes, discuter, etc. > > Pour faire tout �a, il faut �tre aussi convaincu. � ce moment �a > ne doit pas pas �tre trop une corv�e... Oui, sur. Mais en l'occurence, moi je suis pas convaincu de la justesse des arguments, ou plutot que leur avantages en valent le prix a payer. Si c'etait le cas alors oui, je prendrait le temps, mais comme ce n'est pas le cas, alors c'est aux personnes concernes a aller defendre leurs idees, mais avec un ton plus conciliant que ce qu'on lit ici. Amicalement, Sven Luther
