pmarion wrote:Je me vois mal expliquer cela à un utilisateur lambda.
Fedora n'est peut-être pas la distribution la plus adaptée pour les utilisateurs lambda 😉

Si tu as des utilisateurs lambda à gérer, le mieux est encore de faire un dépôt local sur ton réseau, ce qui te permet de tester les mises à jour avant les utilisateurs.
D'habitude, nous constations un décalage de 24/48H (24/48H de trop) mais là nous dépassons ce genre de délai.
Comme je l'ai dit, c'est exceptionnel.
Les dépendances ne sont pas faites pour les chiens. Ce matin 67 mises à jour comment vérifier qu'il n'y a pas dans ces 65 mises à jour une mise à jour qui va planter d'autres compostant.

Il y aurait certainement un moyen de créer un paquet supplémentaire kernel_kmod dont la dépendance serait kernel ET kmod au même niveau.
Fedora ne fera jamais un tel paquetage. Je te rappelle que Fedora est 100% libre et que le dépôt Livna produit des paquetages non-libres.
Et dans ce cas un utilisateur pourrait lancer les mises à jour sans avoir la peur au ventre ou sans devoir faire un travail qui ne lui incombe pas.
Je savais pas qu'on pouvait avoir la peur au ventre dans ce genre de situation 😉
marcet wrote:Fedora ne fera jamais un tel paquetage. Je te rappelle que Fedora est 100% libre et que le dépôt Livna produit des paquetages non-libres
Je n'ai jamais dit que c'était à fedora de le faire.
marcet wrote:Fedora n'est peut-être pas la distribution la plus adaptée pour les utilisateurs lambda
Je ne savais pas fedora aussi élitiste.

Faut-il avoir un CAF (Certificat d'aptitude à fedora) pour utiliser fedora ?

Sur ce forum nous avons en permanence des débutants que nous essayons d'aider. Ne les rebutons pas.
Solution simple : Utilisez des drivers Libres.
pmarion wrote:Je n'ai jamais dit que c'était à fedora de le faire.
Dans ce cas ça ne sert à rien.
Faut-il avoir un CAF (Certificat d'aptitude à fedora) pour utiliser fedora ?
Non, mais il ne faut pas perdre de vue que c'est une distribution qui se veut à la pointe de la nouveauté.
Sur ce forum nous avons en permanence des débutants que nous essayons d'aider. Ne les rebutons pas.
Loin de moi cette pensée, et tu sais bien que je suis parmi les premier à les aider quand je le peux. Seulement il est bon de rappeler que ce genre de choses peut se produire.
Mais peu importe, puisque le forum est là pour savoir comment réagir quand ça arrive 😉
@Marcet
Si cela n'arrivait pas, nous aurions plus de temps à passer sur d'autres problèmes !
Il suffit de voir combien de posts sur les kmod, sur rhgb et l'arrêt graphique (pour ne citer qu'eux).
louizatakk wrote:Solution simple : Utilisez des drivers Libres.
Comme dirai la mère Denis (paix à son âme) : "Ca c'est vrai çà !".
pmarion wrote:@nouv09
Tu es en train de nous dire que :
update IS testing
alors que pour moi
update IS NOT testing
Je vais même plus loin : je dis que Fedora entière est testing. En fait c'est bien de ça que tu te plains si j'ai bien suivi?

Je conserve une F6 qui tourne comme une horloge, mais sachant que je devrai l'abandonner un jour pour une question d'incompatibilité et j'ai une (non deux) centos 5.2. Ca ce n'est pas testing .
Sans aller jusqu'à tourner avec Fedora 6, on peut très bien différer les mises à jour, ça suffit en général pour garder sa distrib stable.
@Marcet
Je repose alors ma question comment faire :
yum --je_ne_veux_pas_les_fichiers_de_moins_de_30_jours update

Si on laisse les paquets sensibles dans testing suffisamment longtemps pour qu'il soient testés avant de les balancer dans update on a bien

update IS NOT testing
pmarion wrote:@Marcet
Je repose alors ma question comment faire :
yum --je_ne_veux_pas_les_fichiers_de_moins_de_30_jours update

Si on laisse les paquets sensibles dans testing suffisamment longtemps pour qu'il soient testés avant de les balancer dans update on a bien
Rire,

Sérieusement je n'en sais rien. J'imagine que si on crée chez soi un mirroir de Fedora on doit pouvoir trier selon les dates et heures des fichiers.

Mais si on trouve la solution à ça et qu'on télécharge un fichier âgé de 35 jours mais comportant un bug qui est corrigé dans un fichier qui lui n'a que 10 jours, quel est le résultat ?
LOOPING wrote:bonjour,
je suis débutant sous fédora et jamais utiliser linux auparavant...
Juste pour savoir si on peut utiliser les fonctions de hachage sha-224 à sha-512 sous fedora ? si oui comment ???
Help please 🙁
[Bash.fr]



[/Bash.fr]

@+
bonjour,
je suis débutant sous fédora et jamais utiliser linux auparavant...
Juste pour savoir si on peut utiliser les fonctions de hachage sha-224 à sha-512 sous fedora ? si oui comment ???
Help please sad
Juste pour calmer un peu le jeu, il faut savoir que si les kmod-nividia pour kernel 2.6.26 mettent autant de temps pour être disponible c'est simplement du au fait que 2 systèmes utilisés chez livna sont tombés en même (le serveur SVN pour les sources et le buildsys qui est le serveur effectuant les builds et plaçant ces build dans les dépôts).

Actuellement, le serveur SVN a été redémarré mais il reste encore le buildsys. Grâce au premier redémarrage, un membre de livna a buildé manuellement et hébergé hors dépôt les kmod pour Fedora9 et un utilisateur possédant Fedora 8 et Fedora 9 a effectué le build manuel pour Fedora 8. Ces derniers paquets sont eux aussi hébergés hors dépôts. Les pakcgaes pour Fedora 8 et 9 sont donc téléchargeables.
Donc pour ceux que ça intéresse, l'installation des kmod pour kernel 2.6.26 peut être effecutée via rpm. Sinon ben alors faites preuve de patience et dés que le serveur buildsys sera redémarré, les dépôts et les miroirs seront mise à jour.

Par conséquent, je ne blâmerai ni Fedora ni livna, car les 1er ne pouvaient pas savoir qu'il y aurait un plantage chez livna et les seconds ne sont pas responsables d'un plantage informatique car cela peut arriver et ne s'annonce pas 😉.
De plus le groupe Fedora devait-il bloquer la mise à jour d'une kernel pour 1 seul type de matériel (uniquement les cartes graphiqes nvidia) ? Personnellement je ne le pense pas et je peux vous dire que j'utilise une carte nvidia et que j'ai été piégé mais je prend mon mal en patience en utilisant akmod.

lionelh
lionelh wrote:Juste pour calmer un peu le jeu, il faut savoir que si les kmod-nividia pour kernel 2.6.26 mettent autant de temps pour être disponible c'est simplement du au fait que 2 systèmes utilisés chez livna sont tombés en même (le serveur SVN pour les sources et le buildsys qui est le serveur effectuant les builds et plaçant ces build dans les dépôts).
Par contre ils ne disent pas suite à quoi. Quelqu'un sait ?
Peut-être qu'ils utilisaient CYGWIN sous WINDOW$ ?
Que dire des procédures de backup et haute disponibilité ?
5 jours plus tard
@lionelh: le problème évoqué ici est récurrant depuis le début des Fedora Core.
Marcet wrote:on peut très bien différer les mises à jour, ça suffit en général pour garder sa distrib stable
Fedora n'est peut-être pas la distribution la plus adaptée pour les utilisateurs lambda
@Marcet: Donc tu es d'accord avec mon 1er post.
@pmarion & cx42net & nouvo09: on est d'accord.

Et puis pourquoi stopper la distrib, c'est riddicule, vu le nombre d'utilisateurs + les goodies ^^ , pourquoi devrait-on se tourner vers une autre distrib?
Ca sert à quoi de créer une communauté et le lendemain tout casser sous prétexte que le support sera arrêté?
On efface tout et on recommence ?

Alors pourquoi une Fedora 10, qu'elle est l'utilité ? pour allez pleurrer sur un Forum parcequ'on est bloqué après une MAJ ou sur une configuration....
#Pfff1: mais non c'est pour être à la pointe de la technologie..
#Pfff2: Pfff!

L'informatique repose essentiellement sur les mathématiques, autrement dit on peut avoir une Fedora sans avoir besoin de 1000 versions pour évoluer.
Si le code est cohérent comme un théorème alors on peut avoir 0 bugs = stabilité. Seules les failles peuvent existées encore.
L'idée c'est comment faire évoluer un noyau en gardant une rétro-compatibilité sur les anciens programmes qui devront subir une MaJ par la suite?
C'est là qu'est tout le challenge pour des distrib grand public.

Perso j'en rien à secoué d'avoir les dernières versions qui bugs.
LOOPING wrote:Perso j'en rien à secoué d'avoir les dernières versions qui bugs.
T'as dû te tromper de distro alors.

Essaye une debian 4.0 (stable)
@louizatakk
Mais non, à partir du moment où l'on n'utilise que 'update' (et non pas 'testing' ou 'rawhide') on peut espérer une version opérationnelle sinon stable.

update IS NOT testing
louizatakk wrote:
LOOPING wrote:Perso j'en rien à secoué d'avoir les dernières versions qui bugs.
T'as dû te tromper de distro alors.

Essaye une debian 4.0 (stable)
Eh bien oui ! Quand on a une philosophie particulière quant à son usage de l'informatique, on essaie de trouver la distribution qui a la même philosophie, et on ne va pas demander à une distribution qui n'a pas la même philosophie, d'en changer.

Pour toi, sans aucun doute, c'est sûrement plus debian que fedora qui saura répondre à ta façon de faire.
Miracle, Miracle, ........
Ce matin 30 mises à jour and the winner is LIVNA 
# egrep 'kernel|nvidia' yum.log | grep 'Oct 02'
Oct 02 08:03:04 Installed: kernel-2.6.26.5-45.fc9.i686
Oct 02 08:03:21 Installed: kernel-devel-2.6.26.5-45.fc9.i686
Oct 02 08:03:27 Updated: kernel-headers-2.6.26.5-45.fc9.i386
Oct 02 08:03:33 Updated: kmod-nvidia-173.14.12-5.lvn9.i686
Oct 02 08:03:34 Installed: kmod-nvidia-2.6.26.5-45.fc9.i686-173.14.12-5.lvn9.i686
Oct 02 08:03:43 Installed: kernel-2.6.26.5-45.fc9.i686
Encore un petit effort et livna sortira le kmod avant le kernel ! ! !