Ca va troller dans les chaumières - Page 5

Ils citent Knoppix dans le document que tu as mis, Kevin . Donc je dirais que par causalité, c'est postérieur.

Kevin Kofler
:

fabetal_ :
et ce n'est pas parce que RH va faire un live cd que ça montre que c'est une distrib populaire etc ... au contraire, ils sont obligés de le faire eux-même parce que personne n'a songé à partir d'une base Fedora pour faire un Live-CD

Tu sais lire? Il y en a déjà 3, cf. mes liens.

bah oui mais je fais exprès de pas avoir vu, comme tu fais des fois

t'as raison en fait c'est une bonne tactique pour pas répondre

spectras :
Ils citent Knoppix dans le document que tu as mis, Kevin . Donc je dirais que par causalité, c'est postérieur.

C'est normal, Knoppix est sorti avant Fedora aussi (ça s'appelait encore RHL). Et il est évident que c'est Knoppix qui a rendu populaire cette idée de Live CD, les CDs MandrakeLive, Gentoo Live CD etc. sont aussi apparus après Knoppix.

Et StatelessLinux.pdf dit que faire une Live CD à partir de Fedora sera trivial quand ils auront implémenté cette feature:
1. installer Fedora en activant l'option stateless et tous les paquets qu'on veut mettre sur le CD
2. choisir "write this install to a CD" dans un menu
et c'est fait. Pas besoin de modifier des paquets comme le fait Knoppix (par exemple, Knoppix rajoute la libkudzu, développée par Red Hat; il n'y a pas de détection de matériel suffisamment bonne pour un Live CD dans Debian).

(troll successfully launched )

Euh sinon il me semble que MEPIS n'utilise pas la libkudzu.

D'ailleurs, une version de développement de Stateless Linux est déjà disponible: http://fedora.redhat.com/docs/stateless/index.html.
http://people.redhat.com/dmalcolm/stateless/RPMS/

Kevin Kofler :
Pas besoin de modifier des paquets comme le fait Knoppix (par exemple, Knoppix rajoute la libkudzu, développée par Red Hat; il n'y a pas de détection de matériel suffisamment bonne pour un Live CD dans Debian).

kudzu est dans Debian... tout comme plein d'autres trucs pour la détection de matériel (http://www.linuxgazette.com/book/print/826).

Kevin Kofler
:

kim
: hmmm, RH seraient-ils en retard ? Debian, Gentoo, Mandrake (me semble-t-il aussi) propose déjà cette "feature" depuis bien longtemps.

Ben non, pas vraiment.
http://people.redhat.com/~hp/stateless/StatelessLinux.pdf

Ben si, là, ils réinventent la roue. Tout ce que dit ton pdf, on peut le faire avec les outils déjà disponibles sous gentoo (par exemple, parce que je connais mieux gentoo).

par exemple (pris sur les changelog) :
livecd-ng : 31 janvier 2003
catalyst : 17 février 2004
deux outils plutôt performant (avec une préférence pour catalyst) pour se créer son iso.

Debian a également son application pour créer une livecd

Je cite de plus l'excellent projet metadistros qui permet de faire une livecd à partir de n'importe quelle distrib.


Oui, red hat prend le train alors qu'il est en marche.

nitro
:

Kevin Kofler :
Pas besoin de modifier des paquets comme le fait Knoppix (par exemple, Knoppix rajoute la libkudzu, développée par Red Hat; il n'y a pas de détection de matériel suffisamment bonne pour un Live CD dans Debian).

kudzu est dans Debian... tout comme plein d'autres trucs pour la détection de matériel (http://www.linuxgazette.com/book/print/826).

Hmmmm, une question comme ça, la LiveCD de RH va utiliser quel format de fs comprimé ? Si c'est du cloop, ça vient... de knoppix. Si c'est du romfs, du squashfs, tu cramfs, c'est tout des projets indépendants de RH. Dire que la libkudzu est développer par RH, c'est bien beau, mais ce n'est pas un tout, c'est un élément. Finalement, mineur. D'autres moyens aussi bons que kudzu existent pour faire de la detection de matérielle. Et mine de rien, la detection matérielle, quand on y réflechit un peu, c'est pas *dur* à faire.

Une LiveCD, une fois qu'on a compris le principe, c'est simple également. Pourquoi RH n'a pas fait de LiveCD avant, alors que c'est un excellent moyen de populariser une distribution ? (genre knoppix a failli convaincre mes parents qui n'y connaissent rien en info, c'est moi qui leur ait dit que c'était pas encore le bon moment, et que j'avais pas envie de configurer leurs périphériques - scanner, webcam, appareil photo, imprimante, etc.-)



Enfin, 3 LiveCD, c'est peu. Quand on voit que certains proposent même des liveUSB et autres joyeusetés (oui gentoo peut le faire, c'est assez simple d'ailleurs).

Et si RH ne faisait qu'imiter, mais mal ?

Elle a un système de testing, mais est pas fouttu de mettre udev à jour avant de faire une release (alors que bon, quand on sait d'avance que le udev en question pose problème...) et donc passe un peu pour des guignols pour des détails à la con (passer de FC1 à FC2... mais comment faire simplement sans que ça merde...).

Elle a un système de paquets, très bien d'ailleurs, mais finalement elle n'arrive pas à en tirer partie (avec le système testing/stable etc.). Je vois, la gentoo, jamais eu de problèmes, toujours bien. Les personnes utilisant les CVS pour faire un rsync sont très peu nombreuses, et pourtant c'est une distrib qui marche.

Elle a une installation qui prend l'administrateur pour un guignol. On te propose 3-4 sets de paquets, dedans je compte même pas le nombre de machins à enlever après, du coup, t'installes rien et tu mets tout au fur et à mesure après . Mandrake propose aussi des sets d'installation, mais au moins, on peut choisir manuellement ce qu'on veut tout de suite, c'est bien. Debian aussi. (je parlerai pas de gentoo, de toute façon c'est pas le même mode d'installation )

Non, décidément, je ne comprendrai jamais RH.

kim :
Non, décidément, je ne comprendrai jamais RH.

Ben ils sont là pour faire de l'argent, contrairement à Debian, Gentoo, etc...

kim
: Hmmmm, une question comme ça, la LiveCD de RH va utiliser quel format de fs comprimé ?

http://fedora.redhat.com/docs/stateless/sn-live-cd.html -> zisofs

D'autres moyens aussi bons que kudzu existent pour faire de la detection de matérielle.

Knoppix est reconnue universalement comme ayant la meilleure détection du matériel sur le marché, ce qui ne serait pas le cas sans le travail que Red Hat a fourni pour libkudzu.

Et mine de rien, la detection matérielle, quand on y réflechit un peu, c'est pas *dur* à faire.

Oh que si! Il y a des tonnes de matériels différents!

Elle a un système de testing, mais est pas fouttu de mettre udev à jour avant de faire une release (alors que bon, quand on sait d'avance que le udev en question pose problème...)

Hein? "Quand on sait d'avance"? Ils ne le savaient pas avant le freeze, sinon ils auraient mis la mise à jour dans la release, évidemment! Ils ne peuvent pas changer les paquets quand ils ont déjà créé les ISOs et sont en train de les uploader sur les miroirs...

et donc passe un peu pour des guignols pour des détails à la con (passer de FC1 à FC2... mais comment faire simplement sans que ça merde...).

apt-get dist-upgrade a marché pour moi. (Anaconda a refusé de travailler avec mes 128 MO de RAM. Ils disent que c'est corrigé dans FC3, je n'ai pas encore eu l'occasion d'essayer.)

Elle a une installation qui prend l'administrateur pour un guignol.

C'est vrai que ça a régressé par rapport aux bonnes vieilles RHL. Mais bon, j'ajuste mes choix de paquets après, avec Synaptic qui ignore toutes ces histoires de "groupes" de paquets.

nitro
:

kim :
Non, décidément, je ne comprendrai jamais RH.

Ben ils sont là pour faire de l'argent, contrairement à Debian, Gentoo, etc...

Certes, c'est une entreprise, mais ils ne gagnent pas un sou avec Fedora... Avec RHEL oui, et nous les aidons à rendre RHEL stable avec nos bug reports de Fedora, mais Debian profite aussi pas mal de nos bug reports vu le retard qu'ils ont.

Et t'as pas honte d'aider RH à se faire de l'argent ? Tu me déçois Kevin là je ne te reconnais plus

Tant que ce n'est pas moi qui le paye...

Donc tu n'es pas un idéaliste aveuglé mais juste un gros rapia ? Tu baisses encore plus dans mon estime là :]

Euh je vois pas pourquoi vous vous gueulez dessus pour savoir qui réutilise quoi étant donné que c'est un peu ça l'avantage du libre ...

Au passage, il n'y a pas que SourceForge. Wikipedia utilise FC2 sur 27 de leurs 32 machines, RHL/FC sur 28 (il y a une machine sur RHL9): http://meta.wikimedia.org/wiki/Wikimedia_servers.

Et puis tiens, j'ai oublié de répondre à ça:

kim
: Et si RH ne faisait qu'imiter, mais mal ?

Red Hat "ne faire qu'imiter"? Qui a sorti en premier (*) GCC post-2.95 (2.96-rh)? glibc 2.3? NPTL? 4KSTACKS? X.Org X11R6.7? X.Org X11R6.8? GCJ (le logiciel qui va libérer tous les logiciels libres écrits en Java de la clôture dans le monde propriétaire)? Qui a développé un thème commun entre KDE et GNOME (qui ne soit pas un thème "Redmond" qui ne fait qu'imiter M$)? Qui participe activement au développement du noyau (Alan Cox, Rik van Riel, Dave Jones, Arjan van de Ven etc.), de GCC (une très grande partie des développeurs de GCC travaillent pour RH) et tous les autres outils de développement (Binutils etc.), de GCJ (Tom Tromey et.al.), de GNOME (Havoc Pennington et.al.), de X.Org (Mike Harris) etc.? D'ailleurs, cela répond aussi à la question de Ximoon: je n'ai rien contre le fait que RH se fait du fric parce qu'ils l'utilisent pour faire avancer le monde du libre.

(*) parmi les grandes distributions, et officiellement. Je n'exclus pas que quelqu'un ait implémenté une distribution basé sur les mêmes logiciels avant, mais je ne les ai vues nulle part. Il est aussi possible que des portages Gentoo aient été disponibles pour certains de ces paquets avant, mais je parle de releases officielles installées par défaut, pas de paquets optionnels et/ou masqués. De plus, toutes les indications sont évidemment sous réserve d'erreurs.

Kevin Kofler :
Oh que si! Il y a des tonnes de matériels différents!

Merci de dire ce que j'attendais ^^
Ce n'est *qu'une* liste de matériel. Ce n'est pas ce que j'appelle une difficulté.

Hein? "Quand on sait d'avance"? Ils ne le savaient pas avant le freeze, sinon ils auraient mis la mise à jour dans la release, évidemment! Ils ne peuvent pas changer les paquets quand ils ont déjà créé les ISOs et sont en train de les uploader sur les miroirs...

Une ISO ça se teste avant de la proposer.
D'autant que (souvenirs) c'est quelle version de udev qui est proposé ? (Alors qu'il y en avait de plus récentes).
udev est un dispositif *essentiel* au bon fonctionnement d'une distribution. Si c'est pas suffisamment testé et donc plante, la distribution ne... sert à rien.

apt-get dist-upgrade a marché pour moi. (Anaconda a refusé de travailler avec mes 128 MO de RAM. Ils disent que c'est corrigé dans FC3, je n'ai pas encore eu l'occasion d'essayer.)

apt n'est pas l'outil "officiel" de FC. Je veux dire, si je suis débutant sous FC, je n'utiliserai certainement pas apt, mais l'outil par défaut proposé par FC. En l'occurrence, avec celui-ci, le passage de FC1 à FC2 n'était pas la panacée. Faudra m'expliquer comment ça se fait.
C'est pas le même fonctionnement, mais par exemple, le passage sous gentoo d'une release à une autre est automatique et quasi transparent (une release n'est qu'un snapshot de Portage à un instant donné). Celui de Mandrake d'une version à une autre est tout aussi facile et surtout, ne génère pas de problème. etc. Comment fait FC pour ne pas y arriver ?

C'est vrai que ça a régressé par rapport aux bonnes vieilles RHL. Mais bon, j'ajuste mes choix de paquets après, avec Synaptic qui ignore toutes ces histoires de "groupes" de paquets.

Voilà, c'est en fait ce que je reproche à FC : devoir faire une installation après l'installation, alors qu'avant on pouvait tout faire en bloc. Je me souviens de mes RH de y'a quelques années, elles étaient bien, pour ça. Je trouve que la tentative de "simplification" qu'ils ont fait tend vers une neuneufication () : mais pourquoi ne pas donner des moyen supplémentaires, qu'on avait avant, et qui plaisaient bien aux gens !

Je ferai le reste plus tard, j'pars en cours :/ (he ouais y'en a qui font pas le pont du 11 novembre)

je suis en FC3 test 3 , j'ai simplement installé les CD par dessus ma FC2 (donc c comme une grosse maj)


résultat: aucun problème, même pas le plus petit. Pourtant ct des tests

Enfin, avec Mandrake, il est quand même fortement recommandé de faire une réinstall complête si on ne veut pas qu'il laisse des trucs moisis de la vielle version avec des dépendances cassées un peu partout (jamais rien de grave, hein, mais souvent un peu de place perdue pour rien pour un outil qui a été transformé, ou fusionné avec un autre, et la mise à jour ne pense pas toujours à supprimer l'ancien devenu inutile).

kim
:

Kevin Kofler :
Oh que si! Il y a des tonnes de matériels différents!

Merci de dire ce que j'attendais ^^ Ce n'est *qu'une* liste de matériel. Ce n'est pas ce que j'appelle une difficulté.

Fais-la alors (sans la piquer à RH )...

Hein? "Quand on sait d'avance"? Ils ne le savaient pas avant le freeze, sinon ils auraient mis la mise à jour dans la release, évidemment! Ils ne peuvent pas changer les paquets quand ils ont déjà créé les ISOs et sont en train de les uploader sur les miroirs...

Une ISO ça se teste avant de la proposer.

Ben, ils ont mis des ISOs Release Candidate en ligne, si personne n'a vu le problème, que veux-tu qu'ils y fassent?

D'autant que (souvenirs) c'est quelle version de udev qui est proposé ? (Alors qu'il y en avait de plus récentes).

Si j'ai bien compris, le problème n'a aucun rapport avec ça, c'était un bogue dans un patch de RH.

udev est un dispositif *essentiel* au bon fonctionnement d'une distribution. Si c'est pas suffisamment testé et donc plante, la distribution ne... sert à rien.

Ça ne plante pas, ça refuse juste de détecter certain matériel (les lecteurs CD notamment) correctement, et une mise à jour du paquet (sortie pratiquement en même temps que FC3) résout le problème.

apt-get dist-upgrade a marché pour moi. (Anaconda a refusé de travailler avec mes 128 MO de RAM. Ils disent que c'est corrigé dans FC3, je n'ai pas encore eu l'occasion d'essayer.)

apt n'est pas l'outil "officiel" de FC. Je veux dire, si je suis débutant sous FC, je n'utiliserai certainement pas apt, mais l'outil par défaut proposé par FC. En l'occurrence, avec celui-ci, le passage de FC1 à FC2 n'était pas la panacée. Faudra m'expliquer comment ça se fait.

Quel outil par défaut?
* Avec yum, qui est livré avec FC par défaut, la mise à jour marche à peu près de la même manière qu'avec apt.
* up2date propose un switch pour mettre à jour la distribution, mais c'est vrai que ce switch est peu ou pas testé parce que les gens qui utilisent up2date ne sont pas ceux qui mettent à jour Fedora sans passer par l'installeur.
* Quant à l'installeur Anaconda, qui est la méthode de mise à jour recommandée, il marche très bien si on a suffisamment de RAM (160 MO suffisent, c'est avec 128 qu'il y avait un problème). Et celui de la FC3 a été dit demander moins de RAM dans les entrées de Bugzilla parlant de ce sujet, je vais l'essayer quand j'aurai le temps, quand les Fedora Extras pour FC3 seront prêts et quand RH aura corrigé les bogues.

Comment fait FC pour ne pas y arriver ?

Tu as au moins 4 méthodes de mise à jour (anaconda, up2date, yum, apt-rpm), si tu n'arrives pas à faire fonctionner au moins une, tu n'es pas doué. Anaconda mache très bien avec suffisamment de RAM.

Voilà, c'est en fait ce que je reproche à FC : devoir faire une installation après l'installation, alors qu'avant on pouvait tout faire en bloc. Je me souviens de mes RH de y'a quelques années, elles étaient bien, pour ça. Je trouve que la tentative de "simplification" qu'ils ont fait tend vers une neuneufication () : mais pourquoi ne pas donner des moyen supplémentaires, qu'on avait avant, et qui plaisaient bien aux gens !

Là, je suis d'accord, mais comme déjà dit, ce genre de trucs ne me dérangent pas trop, tant qu'il y a au moins une solution au problème.

Nil
: Enfin, avec Mandrake, il est quand même fortement recommandé de faire une réinstall complête si on ne veut pas qu'il laisse des trucs moisis de la vielle version avec des dépendances cassées un peu partout

Avec Fedora aussi. Cela dit, mon Linux mis à jour RHL7.3->FC1->FC2 se porte très bien.

Kevin Kofler :
Merci de dire ce que j'attendais ^^ Ce n'est *qu'une* liste de matériel. Ce n'est pas ce que j'appelle une difficulté.

Fais-la alors (sans la piquer à RH )...
[/cite]
Euuuh ce genre de choses, c'est pas compliqué, tu fais une préliste, tu diffuses, si il manque un bout, upgrade, etc. Non, franchement, je ne vois pas de difficulté là dedans.

Ben, ils ont mis des ISOs Release Candidate en ligne, si personne n'a vu le problème, que veux-tu qu'ils y fassent?

Qu'ils attendent un peu plus peut-être ? Par contre là j'ai la flemme de chercher... combien de temps entre la dernière RC et la sortie FC3 ?

Sinon, bah, rien, ils ne peuvent rien faire. Mais si le problème est survenu quoi... quelques heures après la sortie, je trouve qu'il y a un problème quelque part de toute façon.

Si j'ai bien compris, le problème n'a aucun rapport avec ça, c'était un bogue dans un patch de RH.

En fait, ils patchent une ancienne version. Et c'est le combo entre les deux qui allaient pas, donc nouveau patch ^^
FC, c'est les rois du patch, pour ça y'a pas à dire, ils sont forts

Ça ne plante pas, ça refuse juste de détecter certain matériel (les lecteurs CD notamment) correctement, et une mise à jour du paquet (sortie pratiquement en même temps que FC3) résout le problème.

C'est ce que j'appelle un plantage sur le processus de détection de certains matériels

* Quant à l'installeur Anaconda, qui est la méthode de mise à jour recommandée, il marche très bien si on a suffisamment de RAM (160 MO suffisent, c'est avec 128 qu'il y avait un problème). Et celui de la FC3 a été dit demander moins de RAM dans les entrées de Bugzilla parlant de ce sujet, je vais l'essayer quand j'aurai le temps, quand les Fedora Extras pour FC3 seront prêts et quand RH aura corrigé les bogues.

Je parlais effectivement de celui-là. Donc FC est recommandé pour les riches, ou 128Mo de ram c'est obsolète ?

Tu as au moins 4 méthodes de mise à jour (anaconda, up2date, yum, apt-rpm), si tu n'arrives pas à faire fonctionner au moins une, tu n'es pas doué. Anaconda mache très bien avec suffisamment de RAM.

Ho t'inquiete, j'ai pas de quoi télecharger les isos, ni même de quoi maintenir une distrib à jour, alors je n'ai pas testé oui je sais, mais ne dis pas que je suis pas doué

Là, je suis d'accord, mais comme déjà dit, ce genre de trucs ne me dérangent pas trop, tant qu'il y a au moins une solution au problème.

Il se résoud, mais il n'empêche qu'ils ont enlevé ce que j'appelle une killing feature. C'est pas forcément malin de leur part.

kim
: Euuuh ce genre de choses, c'est pas compliqué, tu fais une préliste, tu diffuses, si il manque un bout, upgrade, etc. Non, franchement, je ne vois pas de difficulté là dedans.

Tiens, exactement le modèle de développement que tu critiques chez Fedora.

Ben, ils ont mis des ISOs Release Candidate en ligne, si personne n'a vu le problème, que veux-tu qu'ils y fassent?

Qu'ils attendent un peu plus peut-être ? Par contre là j'ai la flemme de chercher... combien de temps entre la dernière RC et la sortie FC3 ?

RC5: 29 octobre, freeze final (packaging, mirroring): 5 novembre
Remarque qu'ils étaient censés être en "absolute devel freeze" depuis le 20 octobre déjà, mais il y a toujours des bugfixes critiques qui rentrent. (En revanche, des bugfixes non-critiques ont été refusées par RH et proposées en updates après. Je ne comprends pas trop l'intérêt de refuser un bugfix (développé en octobre) dans les ISOs pour le sortir le même jour en updates, mais bon...)

Sinon, bah, rien, ils ne peuvent rien faire. Mais si le problème est survenu quoi... quelques heures après la sortie, je trouve qu'il y a un problème quelque part de toute façon.

Certes, ils ont fait une bêtise, mais une mise à jour de paquet corrige ça très bien. Avec Fedora, on n'est pas à la mise à jour près (il y en a des tonnes, souvent comptées en MO).

Si j'ai bien compris, le problème n'a aucun rapport avec ça, c'était un bogue dans un patch de RH.

En fait, ils patchent une ancienne version. Et c'est le combo entre les deux qui allaient pas, donc nouveau patch ^^
FC, c'est les rois du patch, pour ça y'a pas à dire, ils sont forts

Hmmm... Je pense bien que TIGCC a plus de patches dans GCC qu'eux.

Ça ne plante pas, ça refuse juste de détecter certain matériel (les lecteurs CD notamment) correctement, et une mise à jour du paquet (sortie pratiquement en même temps que FC3) résout le problème.

C'est ce que j'appelle un plantage sur le processus de détection de certains matériels

La différence est que ça ne fait pas planter le système, donc qu'on peut facilement installer le correctif.

Je parlais effectivement de celui-là. Donc FC est recommandé pour les riches, ou 128Mo de ram c'est obsolète ?

192 MB minimum, 256 MB recommended for graphical. Mais c'est l'installation qui bouffe le plus (même en mode texte), après, on s'en sort avec KDE et 128 MO.

Là, je suis d'accord, mais comme déjà dit, ce genre de trucs ne me dérangent pas trop, tant qu'il y a au moins une solution au problème.

Il se résoud, mais il n'empêche qu'ils ont enlevé ce que j'appelle une killing feature. C'est pas forcément malin de leur part.

Faudrait que je voie si je peux mettre en ligne une version modifiée du boot.iso avec le sélectionneur de paquets des anciennes RHL patché dedans.

Kevin Kofler :
Tiens, exactement le modèle de développement que tu critiques chez Fedora.

Attention, ne confond pas le développement et la mise en oeuvre d'un logiciel *récent* qui vient de se créer à une entité qui a fait ses preuves (combien de version de RH depuis combien d'années ?)

Je n'ai jamais reproché à RH de faire tester ses utilisateurs, loin de là. Simplement, il faut aussi faire la différence entre une alpha, une beta, une pre-release, une RC, une testing, etc. Tu n'as pas l'air de faire la différence.

RC5: 29 octobre, freeze final (packaging, mirroring): 5 novembre

Si tu estimes qu'une pauvre semaine est suffisante, très bien. Moi j'aurai mis minimum 3 semaines. Bon.

Remarque qu'ils étaient censés être en "absolute devel freeze" depuis le 20 octobre déjà,

Si ils ont du retard au début du process, et que le planning est bien fait, ils auraient du avoir le meme retard en fin de process. Ils ont précipité les choses, voilà peut-être un exemple (udev) qu'ils auraient peut etre pu résoudre si ils avaient suivi les durées de freeze.

mais il y a toujours des bugfixes critiques qui rentrent. (En revanche, des bugfixes non-critiques ont été refusées par RH et proposées en updates après. Je ne comprends pas trop l'intérêt de refuser un bugfix (développé en octobre) dans les ISOs pour le sortir le même jour en updates, mais bon...)

oui effectivement. Peut-être pour ne pas encore repousser. Là c'est une politique intérieur, faut voir avec les intégrateurs.

Certes, ils ont fait une bêtise, mais une mise à jour de paquet corrige ça très bien. Avec Fedora, on n'est pas à la mise à jour près (il y en a des tonnes, souvent comptées en MO).

Heureusement qu'une MaJ corrige ça.

192 MB minimum, 256 MB recommended for graphical. Mais c'est l'installation qui bouffe le plus (même en mode texte), après, on s'en sort avec KDE et 128 MO.

gasp, même gentoo s'en sortirait mieux (à l'installation). (ceci est un troll à peine dissimulé)

Faudrait que je voie si je peux mettre en ligne une version modifiée du boot.iso avec le sélectionneur de paquets des anciennes RHL patché dedans.

Je pense que ça pourrait en tout cas en intéresser. Maintenant, c'est surtout la distribution "phare" qui devrait le réintégrer. Enfin bon.

kim
:

RC5: 29 octobre, freeze final (packaging, mirroring): 5 novembre

Si tu estimes qu'une pauvre semaine est suffisante, très bien. Moi j'aurai mis minimum 3 semaines. Bon.

La test3 (normalement la dernière version à tester avant la release) était le 11 octobre. Ils ont intercalé les 5 RCs parce qu'il restait des changements de dernière minute à tester.

Remarque qu'ils étaient censés être en "absolute devel freeze" depuis le 20 octobre déjà,

Si ils ont du retard au début du process, et que le planning est bien fait, ils auraient du avoir le meme retard en fin de process. Ils ont précipité les choses, voilà peut-être un exemple (udev) qu'ils auraient peut etre pu résoudre si ils avaient suivi les durées de freeze.

La "absolute devel freeze" n'a pas été respectée pour FC2 non plus, et probablement pas pour FC1 non plus. Il y a toujours des bugfixes qui sont acceptés tant que les ISOs ne sont pas créés. Et c'est bien! Sinon, on devrait se taper encore plus de 0-day updates...

Certes, ils ont fait une bêtise, mais une mise à jour de paquet corrige ça très bien. Avec Fedora, on n'est pas à la mise à jour près (il y en a des tonnes, souvent comptées en MO).

Heureusement qu'une MaJ corrige ça.

Il n'y a que peu de problèmes qui ne peuvent pas être corrigés par une mise à jour des paquets. En général des problèmes d'installation. Et pour résoudre ces problèmes, ils font des boot.iso inofficiels pour le matériel qui ne marche pas avec les officiels.

192 MB minimum, 256 MB recommended for graphical. Mais c'est l'installation qui bouffe le plus (même en mode texte), après, on s'en sort avec KDE et 128 MO.

gasp, même gentoo s'en sortirait mieux (à l'installation). (ceci est un troll à peine dissimulé)

Bah, je vais te dire comment réagit FC3 quand je l'aurai testé. Je pense que leur minimum officiel (64 MO pour une installation en mode texte) ne sera toujours pas suffisant, mais ils disent que 128 MO devraient passer maintenant:

------- Additional Comment #9 From Jeremy Katz on 2004-10-05 11:27 -------
This should be happier with newer releases.

Faudrait que je voie si je peux mettre en ligne une version modifiée du boot.iso avec le sélectionneur de paquets des anciennes RHL patché dedans.

Je pense que ça pourrait en tout cas en intéresser. Maintenant, c'est surtout la distribution "phare" qui devrait le réintégrer. Enfin bon.

Je pense que les gens qui sont intéressés par le sélecteur de paquets sont aussi ceux qui peuvent aller trouver et télécharger un ISO non-officiel.

192Mo minimum ? quand je pense que Win XP s'installe avec 64Mo ...

160 suffisent (installation graphique, j'ai essayé), et probablement 128 aussi avec FC3 (mais peut-être en mode texte seulement).

même 160, c'est toujours 3 fois plus que pour l'installation graphique de WinXP ....

moui XP sur 64 mégas de ram, faut combien de minutes pour lancer notepad?