C'est une VERSION DE DEVELOPPEMENT !
Rien est fait pour mettre à jour une version Test vers une autre Test ou une finale. Et vice vers ça.
Une Fedora Test n'est pas une testing de Debian !
Lorsqu'on a une Test, les mises à jours ne sont absolument pas garantis.
Par exemple tu as sûrement evolution 1.5 (si c'est Test 1). Ben c'est evolution 1.4 dans la finale (donc apt ne fera pas de mise à jour vers evolution 1.4).
etc...
Je prend un ton énervé mais c'est normal que tu te sois planté car ce n'est indiqué nul part (sauf dans les mailing list Fedora).
Prépares toi à refaire une installation toute fraiche :-)
C'est pas le problème. J'ai jamais vu une doc qui indiquait que "make oldconfig" devait marcher "out of the box".
"make oldconfig" a un mécanisme très basique et pas de raisonnements "avancés" du genre :
- Le driver TOTO pour 2.6.3 a été renommé TITI dans 2.6.4 et maintenant TUTU donc je vire TOTO et je le remplace par TUTU et j'ajoute TRALALA qui avant était intégré à TOTO et je fixe le paramètre LOLO à 4 qui était en dure avant dans TOTO.
"make oldconfig" ne faire RIEN de tout ça (c'est pas compliqué à vérifier il n'y a même pas la version Linux dans le .config). Il n'y a aucune compatibilité ascendante dans les .config. "make oldconfig" remets de l'ordre pour que le .config soit valide. Rien de plus. Donc un "make oldconfig" de 2.6.3 vers 2.6.6 donne un résultat aussi ""(in)satisfesant"" qu'un "make oldconfig" de 2.6.6 vers 2.6.3.
Pas beaucoup plus. La différence était beaucoup plus visible durant le passage 2.0 -> 2.2 et 2.2 -> 2.4.
> Pour la rapidite, les benchs le disent, en pratique c'est pas facile a voir.
En valeur absolue c'est peut être pas facile à voir. A la limite je ne serais pas étonné que les benchs ne soit pas très favorable à 2.6. Par contre je suis bleuffé lorsque j'ai une compilation dans un coin et que je regarde un DVD sans le moindre accro en même temps par exemple.
Il y a un progrès "palpable" à l'utilisation.
> Seulement ca me desole de voir les changelogs qui se suivent et se ressemblent.
Tu veux dire que t'envisage d'abandonner 2.6.6 pour retourner sous un 2.6.1 par exemple ?
J'ai entendu la même chose pour Linux 2.2, 2.4 et maintenant 2.6.
Oui le 2.6 est jeune et moins "stable", "fignolé" qu'un 2.4.
Ça te suprend ?
Pour un 2.6 plus stable en développement il faut attendre l'ouverture de la branche 2.7.
Concrètement, il faut tester le 2.6 et conserver un 2.4 dans le coin s'il y a des problèmes. S'il après l'essai il n'y a pas de problème on peut rester sur un 2.6. Sinon il faut attendre.
Sachant que le 2.4 marche encore très bien et avec plein de drivers, les devs Linux auraient tord de ne pas faire tout de suite "the right thing" au-lieu de se limiter à de petits bug-fixes (si c'est possible...) et de systématiquement tout reporter à la prochaine branche de développement. Ceci impliquerait aussi de ne pas ajouter des fonctionnalités très demandées et qui portants ne représentent pas un gros défi pour les développeurs.
Par exemple tu as été contre l'ajoute ext3 dans linux 2.4.7 ? Tu seras contre l'ajout de Reiserfs v4 dans la branche 2.6 ?
De même les utilisateurs auraient tords de ne pas utiliser un Linux 2.4 stable s'il recherche principalement la stabilité.
C'est quoi un "gros patchs" pour 2.6 ? Souvent se sont des patchs qui ont été longuement testés (par exemple dans la branche mm). Ce ne sont pas des ajouts de dernières minutes ! Ces gros patchs sont aussi rapidement stabilisés dans 2.6 et ne compromettent pas durablement la stabilité du noyau. Jusqu'à maintenant j'ai pas vu de "gros patch" introduit dans Linux 2.6 qui ait été remis en cause par une partie significative des dev Linux.
Reporter tous les "gros/moyen patchs" à la prochaine branche de développement c'est uniquement reporter plus de boulot et avoir une phase de stabilisation de la branche de développement longue/pénible et des sorties plus éloignées de versions "stables". C'est aussi avoir moins de développeurs concentrés pour stabiliser la branche stable (ben oui, il faut ouvrir rapidement la branche de développement car un développeurs qui ne faire qu'attendre des rapports de bug pour faire des petits bug-fix en a rapidement marre).
Je fais confiance en l'intelligence des devs Linux pour décider si un noyau doit être marqué stable ou non et ce qui est permis de faire sur un noyau stable. Se sont des décisions collégiales (dev linux, distributeurs, grands constructeurs, etc...) donc je ne vois pas pourquoi les remettre en cause.
Je fais confiance aux distributeurs pour estimer si un noyau récent peut-être utilisé sur un système critique.
Lorsque Windows 2000 est sorti, beaucoup sont restés plusieurs mois voir années sous NT car la stabilisation de Windows 2000 a été longue. Idem pour Linux. Il n'y a pas de mistère.
Les dèv Linux sont-il "lents" ?
Non. Début 2005 les distributions serveurs/professionnelles pour 2.6 vont remplacer les solutions éprouvées à base de 2.4. Un an pour avoir un 2.6 fignolé ce n'est pas long (voir ce qui ce passe avec les OS proprio pour s'en persuader).
Alors arrêtons de se plaindre surtout que l'on est parti prenante dans Linux 2.6. Si tout le monde testaient Linux 2.5, Linux 2.6 aurait moins de problème (Tu as fait un rapport de bug pour Linux 2.5 ?). Ceci implique d'avoir des serveurs qui tournent sous Linux 2.5, beaucoup d'applications qui tournent sous Linux 2.5, tous les drivers testés par beaucoup de monde avec Linux 2.5, ça implique que les développeurs de drivers doivent maintenir très activement leur driver malgrès les nombreuses modifications qui ont cours dans la branche Linux 2.5 etc... et donc d'avoir des distributions avec Linux 2.5 largement diffusées. C'est contradictoire avec l'appellation "développement" de Linux 2.5.
Impossible d'avoir un Linux 2.6.0 parfait. C'est IMPOSSIBLE.
Puis Linux 2.4 rox toujours.
> Je pense honnêtement qu'il est sorti trop vite*.
Pour toi. Pas pour moi et surement pas pour les développeurs.
Dire que Linux 2.6.0 est sorti trop tôt car il y a beaucoup de modifications dans Linux 2.6.6 c'est comme dire que Mandrake Community sort trop tôt car il y a beaucoup de bug-fix dans Mandrake Official ou que Fedora Core sort trop tôt car RHEL basé sur Fedora Core sort plusieur mois après avec plein de bug-fixe. 2.6.0 indique le début de la stabilisation, que c'est exploitable, que c'est une base de travail pour les autres developpeurs (applis drivers) stable. Ça n'indique pas la fin des développements. Une noyau est très complexe, les conditions d'utilisation sont très très variées, les drivers et les combinaisons de matériel extrèmement nombreuses. Il faut du temps pour arriver à une réelle stabilisation.
Dans ton monde "parfait" il y aurait 2.6.0 et rien après. Faut pas rèver.
Je suis sûre que quelqu'un va me sortir l'exception qui confirme la règle...
J'oubliais : ici j'ai Linux 2.6 depuis 2 mois et pas de problème. Sauf un épisode avec kernel panic lorsque je supprimais un module.
PS : coup de gueule "fatigué" sur les mecs qui critique les devs Linux sans réflechir deux secondes à la complexité ÉNORME de développer Linux. C'est pas tout blanc et tout noir.
Tu vas avoir les boules : http://www.osnews.com/comment.php?news_id=7154&limit=no#241457(...) I have not yet installed Fedora 2, but had recently the same problem with Debian Sid (with 2.6.5). Like you, couldn't boot XP, couldn't reinstall XP, tried FIXMBR, used fdisk & cfdisk to format my HD and create partitions and still failed to reinstall XP. The next thing I did was a base Debian Sid install, execute the command dd if=/dev/zero of=/dev/hda bs=512 count=1 to wipe the mbr which finally cured the mess.
> donc ma question persiste : a partir du momont ou 99,999% des users utilisent un boot loader, comment est il possible que lo noyeau herite d un mauvais CHS ? sachant que si le boot loader utilise un mauvais CHS, il devrait etre incapable de lire le noyeau ...
> En fait, je ne suis pas trop chaud pour cette solution.
> je destine le root-RAID à des serveurs de prod' et je ne me vois pas recompiler un noyau
C'est uniquement pour l'installation. Après c'est inutile.
> j'ai bien essayé avec un support dans le noyau mais il n'a pas booté
J'ai déjà vu ça avec Debian. Ça m'a "saoulé" et j'ai pas insisté. Le noyau que j'avais fait n'avais pas besoin d'initrd (je fais tout le temps ça sur ma bécane perso depuis Linux 2.2).
> Pas tout à fait puisque c'est ce qui t'autorise à démarrer/arrêter le RAID en cours d'exploitation
En général avec deux disques je fais une grosse partition raid. Si nécessaire j'utilise les quota. Plusieurs partitions à la fois c'est vraiment pénibles, pas souple et ça apporte rien du tout en performance.
Tu peux utiliser lsraid pour retrouver les infos nécessaire pour faire un raidtab.
> Pense-bête : 'faut que j'essaie absolument GRUB
Installes une Fedora pour voir. je dis Fedora car je connais, mais la dernière fois que j'ai testé une Mandrake ça marchais bien aussi. Par contre Mandrake n'utilise pas Grub par défaut.
Regarde comment c'est fait après l'installation. Pour un test rapide tu peut mettre ta partition raid sur le même disque dure (mode linear pour que ça traine pas trop).
Ça a l'aire limpide.
Je dis ça, je dis rien, je ne suis pas un spécialiste Debian.
Avec une distribution "normale", ça se fait les doigts d'une main dans le nez et l'autre sur la sourie.
Le seul "truc" c'est d'avoir une petite partition normal pour grub/lilo/noyau. Sur mes disques raids, j'ai 99 % pour raid et 1 % pour /boot.
Un noyau avec raid dedans (et non en modules chargé par initrd) est un plus. Dans ce cas le noyau détecte automatiquement la partition raid et l'active. De plus on peut passer des paramètres au raid via grub ou lilo (pas possible avec initrd). Très utile en cas de "catastrophe".
> Je tenterai bien la même chose avec GRUB...
C'est trivial. Il faut Grub dans une partition "normal".
Pour grub.conf, c'est trivial aussi. C'est comme "comme d'hab" mais avec :
kernel /vmlinuz ro root=/dev/md0.
Ton journal est intéressant mais il fait peur :-)
Une autre possibilité plus simple serait de faire les partitions avec knoppix ou fedora ou ... .
Puis remplacer le noyau "standard" debian de l'installation par un noyau recompilé avec raid "dedans" (si c'est nécessaire). C'est facile à réalisé avec FC2 (ce n'est pas nécessaire pour raid dans le cas de FC2).
Normalement ça doit rouler. Au pire il faudra faire des mknod .... /dev/md0 durant l'installation.
Après l'installation créer un /etc/raidtab qui correspond à la partition raid montée automatiquement. C'est du cosmétique avec l'autodetection de Linux.
Et avec :
rpm -q -l yast2-packagemanager tu ne trouves pas la licence ?
Puis on s'en fous ! Ce sont sources qui comptent !
De plus pour que le binaire est de l'inportance il faut un truc du style : $ gzip --license
gzip 1.3.3
(2002-03-08)
Copyright 2002 Free Software Foundation
Copyright 1992-1993 Jean-loup Gailly
This program comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of this program
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.
Je m'en fous de ça. Ça vient du .spec : License: GPL
C'est le seul truc marqué GPL (avec testinstall.cc qui ne compte pas vraiment) et il n'est pas dans le tar.gz. Les autres trucs GPL viennent de autoconf/automake/libtool/etc. De plus c'est purement indicatif. Si je mets "License : proprio" dans le .spec de la glibc et que je refais les paquets ça change rien. La glibc reste GPL même si rpm -q -i me donne "License: proprio".
J'arrête. Je perd des XPs et tout le monde s'en branle des problèmes de licence.
Bizarre après avoir polluer toutes les news de "suseçapuçaipalibre".
> Bon, visiblement, il y a eu boulette de la part de SuSE, ils ont laissé quelques vieux fichiers,
Il ont laissé des vieux fichiers et pas mis les nouveaux. De plus les vieux fichiers sont toujours pris en compte (copiés dans /usr/share/doc/..../COPYING).
> mais je ne vois pas trop pourquoi ils auraient annoncé qu'ils feraient une release GPL et qu'ils se retireraient au dernier moment ...
Pour les licences il faut être intransigeant. Sinon il y a des "affaires" qui trainent, qui trainent, qui trainent... Par exemple libmysqlclient qui n'est toujours pas fixé malgrès les promesses de MySQL AB qui ont déjà 1 année....
Je dis bien "YAST n'est pas totalement gpl". Quelle distribution oserait prendre yast2-packagemanager qui n'est pas gpl selon les sources (c'est indiscutable) ?
Personne. Il faut recoder cette partie (115 000 lignes de code).
Truc sympatique, il n'y a qu'un fichier qu'ils ont été obligé de mettre avec la licence GPL : testinstall.cc : !THIS CODE IS GPL AS READLINE IS USED!
C'est pour les tests donc ça ne touche pas le reste.
Tous les autres fichiers n'ont aucune référence à la GPL.
Mais quel est le pourcentage ? 1 % ? Je ne sait pas. Par exemple les dev RH/Fedora n'ont pas accédé à la moindre machine avec ce problème. Idem pour des dev de parted. D'où une impression de "laxisme" (légitime) par rapport à ce problème.
Par contre le problème est très grave pour celui qui ne sait pas s'en débarrasser. Un linuxien qui ne va jamais sur les forums, s'il a ce problèm, va le dire à tout le monde.
Je réagissais par rapport au "chezmoiçamarche" sans intérêt car la grande majorité des gens n'ont pas de problème.
> comment un OS (XP) peut il interagire avec un noyeau ... alors qu aucun des deux n est concerne par l autre ?
Je suis d'une patience... Je m'impressionne.
Sur la table de partition il y a la géometrie du disque dure (C/H/S) (pour des raisons historiques). Windows peut utiliser LBA. Windows (son loader) utilisera ce qui est proposé par le BIOS et la geometrie C/H/S retournée par le BIOS si le BIOS n'est pas configuré pour utiliser LBA. Si le BIOS retourne le mode LBA, Windows marche sans problème et ignore les valeurs C/H/S.
L'un des problèmes est la façon dont le BIOS fixe les valeurs C/H/S qu'il va renvoyer à Windows lorsqu'il va lui demander. Normalement on peut penser que le BIOS n'interprète jamais ce qu'il y a sur le disque dure et qu'il doit se limite à l'exécution des 512 premiers octets.
Ben non. S'il voit que les valeurs C/H/S retournées par le disque lui-même et par la table de partition sont différentes il prend les valeurs C/H/S qu'il a trouvé sur la table de partitions. Pourquoi ? Peut-être se dit-il que si les valeurs sont différentes sur la table de partition c'est qu'il y a une bonne raison (il faut savoir que ces valeurs pour les disques moderne sont "virtuelles" donc il n'y a pas de raison de refuser d'autres valeurs du moment que le nombre de secteur total est respecté).
De plus, et c'est là que ça devient "grave", certains BIOS sont "buggés" et si le mode "LBA" est demandé explicitement dans le setting par l'utilisateur, le BIOS continue d'utiliser le mode C/H/S s'il n'y a pas concordance entre les valeurs C/H/S du disque et de la table de partition. Dans ce cas Windows utilisera tout le temps C/H/S alors que LBA ne pose pas de problème. Sans réécrire la table de partition (par exemple avec sfdisk) on ne peut se sortir de ce "merdier".
Pourquoi ça ne plante que sous Windows ? Bon là je suis moins sûre. Ce qui se passe c'est que le loader vérifie les valeurs C/H/S sur la table de partition avec des valeurs stockées sur le FS (NTFS) et le BIOS. S'il n'y a pas concordance alors ça plante.
Pourquoi GNU/Linux stocke des "conneries" ?
Avant, avec Linux 2.4, Linux demandait au BIOS les valeurs C/H/S. Avec Linux 2.6 le noyau ne demande rien au BIOS et "devine" les valeurs C/H/S (il y a CONFIG_EDD depuis peu de temps dans le 2.6 pour "attaquer" directement le BIOS). Sur le papier ce n'est pas un problème puisque ce sont des valeurs "virtuelles". Malheureusement elles peuvent ne pas coller avec les valeurs que le BIOS a précédamment retournées à Windows lors du formatage de NTFS par exemple.
Lorsque parted écrit la table de partition il écrit les valeurs C/H/S que linux 2.6 lui a retourné qui parfois sont fausses. Cette erreur est retournée à windows par la table des partitions et parfois par le BIOS aussi.
Bon, maintenant il reste un problème. Pourquoi parted écrit toujours les valeurs C/H/S sur la table de partition si elles sont déjà là ? C'est un bug.
OUAIS !!!!!!!!!
Je l'ai pas non plus avec Fedora !! (normal, j'ai pas windows).
Youpi !
Qui d'autre ?
Faudrait peut-être comprendre le problème avant de poster des [beep] comme ça.
Si tu as une Debian (ou n'importe quoi d'autre) avec Linux 2.6 + Parted + un dual boot avec win XP et/ou une partition NTFS + un bios pourri + une table de partition écrite en C/H/S alors tu as aussi le bug.
Par contre il est (selon moi) important de communiquer sur ce bug même s'il est rare. En effet, quelques personnes ont refait une installation à partir de zéro en perdant toute leurs données car elles croyaient que "c'était foutu". Pire ! J'ai déjà vu des gens proposer "dd if=/dev/zero of=/dev/hda" pour résoudre ce problème (c'est vrai que ça marche mais c'est brutal).
Enfin, c'est un bug qui est invisible pour ceux qui n'ont pas du Windows. Ce "bug" n'a aucun impacte sur Linux. D'où le fait qu'aucun développeur Linux ne l'ait eu et qu'il est passé un peu inaperçu.
Ceux qui ont installé une Debian avec Linux 2.2 ou 2.4 durant l'installation devrait faire "profile bas" au lieu de rayer leur "petits" camarades. Si la prochaine Sarge avec Linux 2.6 marche sans soucis se sera aussi grace à Mandrake/SuSE/Fedora/... qui auront essuyé les plâtres.
Il y a plein de monde en dual boot Windows XP/Mandrake|SuSE[FC2 qui n'ont pas de problème.
C'est pour les quelques BIOS qui ne permettent pas de forcer le mode LBA.
Et pourquoi tu ne corriges pas le reste ? RedHat va baser sa version desktop sur la Fedora Core 2 en sortant une version entreprise bientôt (actuellement en test).
Tu peux me donner un lien qui indique que "RedHat va baser sa version desktop sur la Fedora Core 2".
Et où as-tu vu la version test de la prochaine RHEL ?
Les versions test d'RHEL sont publiquement accessibles (ce sont des beta pour faire la différence avec Fedora).
Moi j'ai rien vu. Et la prochaine beta RHEL sera pour Septembre/Octobre 2004 (sortie de la finale début 2005). Or la sortie de FC3 est vaguement prévue pour Octoble 2004. Donc il est possible que la prochaine RHEL soit basée sur FC3 (surtout si Gnome 2.6 et kde 3.2 reste dans FC3).
Donc, faut faire des corrections pour ne pas avancer des choses non prouvées ou donnes moi des liens pour me prouver que j'ai tord.
T'es pas obligé de t'énervé car j'ai mal interprété une phrase...
> car depuis la série 8 de la mandrake j'ai souvent était déçu. > > par contre j'ai viré la fedora pour installer la mandrake 10 official, et là j'ai été agréablement surpris par sa rapidité et surtout par sa stabilité
Pas facile de faire la relation avec les Mandrake précédentes alors que juste avant tu parles de la "lenteur" de FC2.
Peut-être que tu as aussi été surpris de la rapidité par rapport aux autres Mandrake et non par rapport à FC2 ?
Mais désolé, c'est vraiment pas évident à deviner (relis ton post) qu'une fois c'est par rapport à FC2 et juste après c'est par rapport aux autres Mandrake.
> j'ai également écris que la FC2 était lente et que j'étais déçu, ce qui est mon droit.
Je sais pas si tu as remarqué, mais j'ai confirmé cet avis :-).
> ils n'ont pas modifé toutes les traudctions de la license
C'est la même chose pour COPYING, COPYRIGHT.english, COPYRIGHT.german, COPYRIGHT.spanish.
Ou alors il faut faire un procès à SuSE car yast ne respecte pas la licence indiqué par rpm. Très hazardeux.... SuSE pouvant dire que la licence ne s'applique qu'au fichier .spec qui n'est pas dans yast2-packagemanager-2.9.37.tar.bz2.
Si je fouille les sources :
Makefile.in HAS_GPL_LICENSE = $(shell test -e $(srcdir)/GPL && echo GPL) Mais il n'y a pas de fichier GPL et il n'y a aucune trace de la licence GPL. COPYRIGHT_files_gpl = GPL README COPYING COPYRIGHT.english
COPYRIGHT_files_yast = README COPYING COPYRIGHT.english \
COPYRIGHT.french COPYRIGHT.german COPYRIGHT.spanish
extra_COPYRIGHT_files = $(if $(HAS_GPL_LICENSE), $(COPYRIGHT_files_gpl), $(COPYRIGHT_files_yast))
Donc, jusqu'à preuve du contraire, ce n'est pas du GPL. Ou alors je suis une grosse buse.
Pour info, voilà le contenu de README : This program/library is part of YaST2
See the file COPYRIGHT.english for license terms
Et COPYRIGHT.english est la licence Yast 2 "classique" et pas la GPL.
# Typique d'une Fedora 2 Test X
Posté par 007 . En réponse au journal Paye ton upgrade de Fedora.... Évalué à -1.
Donc tu avais une Fedora 2 Test 1 ou 2...
C'est une VERSION DE DEVELOPPEMENT !
Rien est fait pour mettre à jour une version Test vers une autre Test ou une finale. Et vice vers ça.
Une Fedora Test n'est pas une testing de Debian !
Lorsqu'on a une Test, les mises à jours ne sont absolument pas garantis.
Par exemple tu as sûrement evolution 1.5 (si c'est Test 1). Ben c'est evolution 1.4 dans la finale (donc apt ne fera pas de mise à jour vers evolution 1.4).
etc...
Je prend un ton énervé mais c'est normal que tu te sois planté car ce n'est indiqué nul part (sauf dans les mailing list Fedora).
Prépares toi à refaire une installation toute fraiche :-)
[^] # Re: 2.6.3-2.6.6 !!!!
Posté par 007 . En réponse au journal Kernel 2.6, 6 mois après. Évalué à 1.
"make oldconfig" a un mécanisme très basique et pas de raisonnements "avancés" du genre :
- Le driver TOTO pour 2.6.3 a été renommé TITI dans 2.6.4 et maintenant TUTU donc je vire TOTO et je le remplace par TUTU et j'ajoute TRALALA qui avant était intégré à TOTO et je fixe le paramètre LOLO à 4 qui était en dure avant dans TOTO.
"make oldconfig" ne faire RIEN de tout ça (c'est pas compliqué à vérifier il n'y a même pas la version Linux dans le .config). Il n'y a aucune compatibilité ascendante dans les .config. "make oldconfig" remets de l'ordre pour que le .config soit valide. Rien de plus. Donc un "make oldconfig" de 2.6.3 vers 2.6.6 donne un résultat aussi ""(in)satisfesant"" qu'un "make oldconfig" de 2.6.6 vers 2.6.3.
[^] # Re: 2.6.3-2.6.6 !!!!
Posté par 007 . En réponse au journal Kernel 2.6, 6 mois après. Évalué à -4.
> avant le 2.6.6 : tout est ok
Je suis consterné. Je vais utiliser mon .config pour 2.6.6 et l'utiliser pour un 2.6.3. Devine quelle sera ma conclusion.
La recompilation d'un noyau n'est pas pour la ménagère de moins de 50 ans.
[^] # Re: Replying...
Posté par 007 . En réponse au journal Kernel 2.6, 6 mois après. Évalué à 4.
Pas beaucoup plus. La différence était beaucoup plus visible durant le passage 2.0 -> 2.2 et 2.2 -> 2.4.
> Pour la rapidite, les benchs le disent, en pratique c'est pas facile a voir.
En valeur absolue c'est peut être pas facile à voir. A la limite je ne serais pas étonné que les benchs ne soit pas très favorable à 2.6. Par contre je suis bleuffé lorsque j'ai une compilation dans un coin et que je regarde un DVD sans le moindre accro en même temps par exemple.
Il y a un progrès "palpable" à l'utilisation.
> Seulement ca me desole de voir les changelogs qui se suivent et se ressemblent.
Tu veux dire que t'envisage d'abandonner 2.6.6 pour retourner sous un 2.6.1 par exemple ?
# Toujours la même histoire...
Posté par 007 . En réponse au journal Kernel 2.6, 6 mois après. Évalué à 9.
Oui le 2.6 est jeune et moins "stable", "fignolé" qu'un 2.4.
Ça te suprend ?
Pour un 2.6 plus stable en développement il faut attendre l'ouverture de la branche 2.7.
Concrètement, il faut tester le 2.6 et conserver un 2.4 dans le coin s'il y a des problèmes. S'il après l'essai il n'y a pas de problème on peut rester sur un 2.6. Sinon il faut attendre.
Sachant que le 2.4 marche encore très bien et avec plein de drivers, les devs Linux auraient tord de ne pas faire tout de suite "the right thing" au-lieu de se limiter à de petits bug-fixes (si c'est possible...) et de systématiquement tout reporter à la prochaine branche de développement. Ceci impliquerait aussi de ne pas ajouter des fonctionnalités très demandées et qui portants ne représentent pas un gros défi pour les développeurs.
Par exemple tu as été contre l'ajoute ext3 dans linux 2.4.7 ? Tu seras contre l'ajout de Reiserfs v4 dans la branche 2.6 ?
De même les utilisateurs auraient tords de ne pas utiliser un Linux 2.4 stable s'il recherche principalement la stabilité.
C'est quoi un "gros patchs" pour 2.6 ? Souvent se sont des patchs qui ont été longuement testés (par exemple dans la branche mm). Ce ne sont pas des ajouts de dernières minutes ! Ces gros patchs sont aussi rapidement stabilisés dans 2.6 et ne compromettent pas durablement la stabilité du noyau. Jusqu'à maintenant j'ai pas vu de "gros patch" introduit dans Linux 2.6 qui ait été remis en cause par une partie significative des dev Linux.
Reporter tous les "gros/moyen patchs" à la prochaine branche de développement c'est uniquement reporter plus de boulot et avoir une phase de stabilisation de la branche de développement longue/pénible et des sorties plus éloignées de versions "stables". C'est aussi avoir moins de développeurs concentrés pour stabiliser la branche stable (ben oui, il faut ouvrir rapidement la branche de développement car un développeurs qui ne faire qu'attendre des rapports de bug pour faire des petits bug-fix en a rapidement marre).
Je fais confiance en l'intelligence des devs Linux pour décider si un noyau doit être marqué stable ou non et ce qui est permis de faire sur un noyau stable. Se sont des décisions collégiales (dev linux, distributeurs, grands constructeurs, etc...) donc je ne vois pas pourquoi les remettre en cause.
Je fais confiance aux distributeurs pour estimer si un noyau récent peut-être utilisé sur un système critique.
Lorsque Windows 2000 est sorti, beaucoup sont restés plusieurs mois voir années sous NT car la stabilisation de Windows 2000 a été longue. Idem pour Linux. Il n'y a pas de mistère.
Les dèv Linux sont-il "lents" ?
Non. Début 2005 les distributions serveurs/professionnelles pour 2.6 vont remplacer les solutions éprouvées à base de 2.4. Un an pour avoir un 2.6 fignolé ce n'est pas long (voir ce qui ce passe avec les OS proprio pour s'en persuader).
Alors arrêtons de se plaindre surtout que l'on est parti prenante dans Linux 2.6. Si tout le monde testaient Linux 2.5, Linux 2.6 aurait moins de problème (Tu as fait un rapport de bug pour Linux 2.5 ?). Ceci implique d'avoir des serveurs qui tournent sous Linux 2.5, beaucoup d'applications qui tournent sous Linux 2.5, tous les drivers testés par beaucoup de monde avec Linux 2.5, ça implique que les développeurs de drivers doivent maintenir très activement leur driver malgrès les nombreuses modifications qui ont cours dans la branche Linux 2.5 etc... et donc d'avoir des distributions avec Linux 2.5 largement diffusées. C'est contradictoire avec l'appellation "développement" de Linux 2.5.
Impossible d'avoir un Linux 2.6.0 parfait. C'est IMPOSSIBLE.
Puis Linux 2.4 rox toujours.
> Je pense honnêtement qu'il est sorti trop vite*.
Pour toi. Pas pour moi et surement pas pour les développeurs.
Dire que Linux 2.6.0 est sorti trop tôt car il y a beaucoup de modifications dans Linux 2.6.6 c'est comme dire que Mandrake Community sort trop tôt car il y a beaucoup de bug-fix dans Mandrake Official ou que Fedora Core sort trop tôt car RHEL basé sur Fedora Core sort plusieur mois après avec plein de bug-fixe. 2.6.0 indique le début de la stabilisation, que c'est exploitable, que c'est une base de travail pour les autres developpeurs (applis drivers) stable. Ça n'indique pas la fin des développements. Une noyau est très complexe, les conditions d'utilisation sont très très variées, les drivers et les combinaisons de matériel extrèmement nombreuses. Il faut du temps pour arriver à une réelle stabilisation.
Dans ton monde "parfait" il y aurait 2.6.0 et rien après. Faut pas rèver.
Je suis sûre que quelqu'un va me sortir l'exception qui confirme la règle...
J'oubliais : ici j'ai Linux 2.6 depuis 2 mois et pas de problème. Sauf un épisode avec kernel panic lorsque je supprimais un module.
PS : coup de gueule "fatigué" sur les mecs qui critique les devs Linux sans réflechir deux secondes à la complexité ÉNORME de développer Linux. C'est pas tout blanc et tout noir.
# Raffarin va "chatter"
Posté par 007 . En réponse au journal Raffarin va "chatter" avec les internautes. Évalué à -6.
[^] # deux
Posté par 007 . En réponse au journal Dual boot WinXP/Linux 2.6. Évalué à 0.
http://www.osnews.com/comment.php?news_id=7154&limit=no#241457(...)
I have not yet installed Fedora 2, but had recently the same problem with Debian Sid (with 2.6.5). Like you, couldn't boot XP, couldn't reinstall XP, tried FIXMBR, used fdisk & cfdisk to format my HD and create partitions and still failed to reinstall XP. The next thing I did was a base Debian Sid install, execute the command dd if=/dev/zero of=/dev/hda bs=512 count=1 to wipe the mbr which finally cured the mess.
Et oui toutes les distributions sont concernées.
[^] # Re: Vous devez entrer un sujet et un commentaire
Posté par 007 . En réponse au journal Dual boot WinXP/Linux 2.6. Évalué à 0.
T'as presque rien compris.
[^] # Re: C'est compliqué....
Posté par 007 . En réponse au journal RAID + boot + LILO : mini-mini HOWTO. Évalué à 1.
> je destine le root-RAID à des serveurs de prod' et je ne me vois pas recompiler un noyau
C'est uniquement pour l'installation. Après c'est inutile.
> j'ai bien essayé avec un support dans le noyau mais il n'a pas booté
J'ai déjà vu ça avec Debian. Ça m'a "saoulé" et j'ai pas insisté. Le noyau que j'avais fait n'avais pas besoin d'initrd (je fais tout le temps ça sur ma bécane perso depuis Linux 2.2).
> Pas tout à fait puisque c'est ce qui t'autorise à démarrer/arrêter le RAID en cours d'exploitation
En général avec deux disques je fais une grosse partition raid. Si nécessaire j'utilise les quota. Plusieurs partitions à la fois c'est vraiment pénibles, pas souple et ça apporte rien du tout en performance.
Tu peux utiliser lsraid pour retrouver les infos nécessaire pour faire un raidtab.
> Pense-bête : 'faut que j'essaie absolument GRUB
Installes une Fedora pour voir. je dis Fedora car je connais, mais la dernière fois que j'ai testé une Mandrake ça marchais bien aussi. Par contre Mandrake n'utilise pas Grub par défaut.
Regarde comment c'est fait après l'installation. Pour un test rapide tu peut mettre ta partition raid sur le même disque dure (mode linear pour que ça traine pas trop).
Ça a l'aire limpide.
Je dis ça, je dis rien, je ne suis pas un spécialiste Debian.
[^] # Re: C'est compliqué....
Posté par 007 . En réponse au journal RAID + boot + LILO : mini-mini HOWTO. Évalué à 2.
Inutile d'installer Fedora ou .... Fais une installation classique et arrête toi après la création des partitions.
# C'est compliqué....
Posté par 007 . En réponse au journal RAID + boot + LILO : mini-mini HOWTO. Évalué à 1.
Le seul "truc" c'est d'avoir une petite partition normal pour grub/lilo/noyau. Sur mes disques raids, j'ai 99 % pour raid et 1 % pour /boot.
Un noyau avec raid dedans (et non en modules chargé par initrd) est un plus. Dans ce cas le noyau détecte automatiquement la partition raid et l'active. De plus on peut passer des paramètres au raid via grub ou lilo (pas possible avec initrd). Très utile en cas de "catastrophe".
> Je tenterai bien la même chose avec GRUB...
C'est trivial. Il faut Grub dans une partition "normal".
Pour grub.conf, c'est trivial aussi. C'est comme "comme d'hab" mais avec :
kernel /vmlinuz ro root=/dev/md0.
Ton journal est intéressant mais il fait peur :-)
Une autre possibilité plus simple serait de faire les partitions avec knoppix ou fedora ou ... .
Puis remplacer le noyau "standard" debian de l'installation par un noyau recompilé avec raid "dedans" (si c'est nécessaire). C'est facile à réalisé avec FC2 (ce n'est pas nécessaire pour raid dans le cas de FC2).
Normalement ça doit rouler. Au pire il faudra faire des mknod .... /dev/md0 durant l'installation.
Après l'installation créer un /etc/raidtab qui correspond à la partition raid montée automatiquement. C'est du cosmétique avec l'autodetection de Linux.
[^] # Re: performances trés moyennes
Posté par 007 . En réponse à la dépêche Test de la Fedora Core 2. Évalué à -2.
[^] # Re: Et une mise à jour ?
Posté par 007 . En réponse à la dépêche Tests en ligne de SUSE LINUX 9.1. Évalué à 1.
C'est comme une FC1 complètement à jours est équivalente à une FC2.
Et Win 98 avec toutes les mises à jours fait un joli Win XP.
Non, je déconne.
[^] # Re: YAST n'est pas totalement gpl
Posté par 007 . En réponse à la dépêche Tests en ligne de SUSE LINUX 9.1. Évalué à 0.
Et avec :
rpm -q -l yast2-packagemanager tu ne trouves pas la licence ?
Puis on s'en fous ! Ce sont sources qui comptent !
De plus pour que le binaire est de l'inportance il faut un truc du style :
$ gzip --license
gzip 1.3.3
(2002-03-08)
Copyright 2002 Free Software Foundation
Copyright 1992-1993 Jean-loup Gailly
This program comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of this program
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.
> rpm -qi yast2-packagemanager | egrep "(License)"
> Size : 2970453 License: GPL
Je m'en fous de ça. Ça vient du .spec :
License: GPL
C'est le seul truc marqué GPL (avec testinstall.cc qui ne compte pas vraiment) et il n'est pas dans le tar.gz. Les autres trucs GPL viennent de autoconf/automake/libtool/etc. De plus c'est purement indicatif. Si je mets "License : proprio" dans le .spec de la glibc et que je refais les paquets ça change rien. La glibc reste GPL même si rpm -q -i me donne "License: proprio".
J'arrête. Je perd des XPs et tout le monde s'en branle des problèmes de licence.
Bizarre après avoir polluer toutes les news de "suseçapuçaipalibre".
[^] # Re: YAST n'est pas totalement gpl
Posté par 007 . En réponse à la dépêche Tests en ligne de SUSE LINUX 9.1. Évalué à -1.
Il ont laissé des vieux fichiers et pas mis les nouveaux. De plus les vieux fichiers sont toujours pris en compte (copiés dans /usr/share/doc/..../COPYING).
> mais je ne vois pas trop pourquoi ils auraient annoncé qu'ils feraient une release GPL et qu'ils se retireraient au dernier moment ...
Pour les licences il faut être intransigeant. Sinon il y a des "affaires" qui trainent, qui trainent, qui trainent... Par exemple libmysqlclient qui n'est toujours pas fixé malgrès les promesses de MySQL AB qui ont déjà 1 année....
Je dis bien "YAST n'est pas totalement gpl". Quelle distribution oserait prendre yast2-packagemanager qui n'est pas gpl selon les sources (c'est indiscutable) ?
Personne. Il faut recoder cette partie (115 000 lignes de code).
Truc sympatique, il n'y a qu'un fichier qu'ils ont été obligé de mettre avec la licence GPL : testinstall.cc :
!THIS CODE IS GPL AS READLINE IS USED!
C'est pour les tests donc ça ne touche pas le reste.
Tous les autres fichiers n'ont aucune référence à la GPL.
[^] # Re: Hein ?
Posté par 007 . En réponse au journal Dual boot WinXP/Linux 2.6. Évalué à 1.
Mais quel est le pourcentage ? 1 % ? Je ne sait pas. Par exemple les dev RH/Fedora n'ont pas accédé à la moindre machine avec ce problème. Idem pour des dev de parted. D'où une impression de "laxisme" (légitime) par rapport à ce problème.
Par contre le problème est très grave pour celui qui ne sait pas s'en débarrasser. Un linuxien qui ne va jamais sur les forums, s'il a ce problèm, va le dire à tout le monde.
Je réagissais par rapport au "chezmoiçamarche" sans intérêt car la grande majorité des gens n'ont pas de problème.
[^] # Re: YAST n'est pas totalement gpl
Posté par 007 . En réponse à la dépêche Tests en ligne de SUSE LINUX 9.1. Évalué à -1.
Donnes moi la valeur retournée par :
$ rpm -q -f /usr/share/doc/packages/yast2/COPYING
C'est yast2-packagemanager ? Sûrement que non.
Fais :
$ rpm -q -l yast2-packagemanager | egrep "(COPYING)|(COPYRIGHT)".
Donne nous le contenu des fichiers. Merci.
C'est les sources qui faut vérifier. Ceux qui sont intéressés par un fork ne vont pas utiliser les binaires !!!!!!!!!!!!!!!
[^] # Re: Vous devez entrer un sujet et un commentaire
Posté par 007 . En réponse au journal Dual boot WinXP/Linux 2.6. Évalué à 5.
Je suis d'une patience... Je m'impressionne.
Sur la table de partition il y a la géometrie du disque dure (C/H/S) (pour des raisons historiques). Windows peut utiliser LBA. Windows (son loader) utilisera ce qui est proposé par le BIOS et la geometrie C/H/S retournée par le BIOS si le BIOS n'est pas configuré pour utiliser LBA. Si le BIOS retourne le mode LBA, Windows marche sans problème et ignore les valeurs C/H/S.
L'un des problèmes est la façon dont le BIOS fixe les valeurs C/H/S qu'il va renvoyer à Windows lorsqu'il va lui demander. Normalement on peut penser que le BIOS n'interprète jamais ce qu'il y a sur le disque dure et qu'il doit se limite à l'exécution des 512 premiers octets.
Ben non. S'il voit que les valeurs C/H/S retournées par le disque lui-même et par la table de partition sont différentes il prend les valeurs C/H/S qu'il a trouvé sur la table de partitions. Pourquoi ? Peut-être se dit-il que si les valeurs sont différentes sur la table de partition c'est qu'il y a une bonne raison (il faut savoir que ces valeurs pour les disques moderne sont "virtuelles" donc il n'y a pas de raison de refuser d'autres valeurs du moment que le nombre de secteur total est respecté).
De plus, et c'est là que ça devient "grave", certains BIOS sont "buggés" et si le mode "LBA" est demandé explicitement dans le setting par l'utilisateur, le BIOS continue d'utiliser le mode C/H/S s'il n'y a pas concordance entre les valeurs C/H/S du disque et de la table de partition. Dans ce cas Windows utilisera tout le temps C/H/S alors que LBA ne pose pas de problème. Sans réécrire la table de partition (par exemple avec sfdisk) on ne peut se sortir de ce "merdier".
Pourquoi ça ne plante que sous Windows ? Bon là je suis moins sûre. Ce qui se passe c'est que le loader vérifie les valeurs C/H/S sur la table de partition avec des valeurs stockées sur le FS (NTFS) et le BIOS. S'il n'y a pas concordance alors ça plante.
Pourquoi GNU/Linux stocke des "conneries" ?
Avant, avec Linux 2.4, Linux demandait au BIOS les valeurs C/H/S. Avec Linux 2.6 le noyau ne demande rien au BIOS et "devine" les valeurs C/H/S (il y a CONFIG_EDD depuis peu de temps dans le 2.6 pour "attaquer" directement le BIOS). Sur le papier ce n'est pas un problème puisque ce sont des valeurs "virtuelles". Malheureusement elles peuvent ne pas coller avec les valeurs que le BIOS a précédamment retournées à Windows lors du formatage de NTFS par exemple.
Lorsque parted écrit la table de partition il écrit les valeurs C/H/S que linux 2.6 lui a retourné qui parfois sont fausses. Cette erreur est retournée à windows par la table des partitions et parfois par le BIOS aussi.
Bon, maintenant il reste un problème. Pourquoi parted écrit toujours les valeurs C/H/S sur la table de partition si elles sont déjà là ? C'est un bug.
La situation est très complexe.
[^] # Re: Hein ?
Posté par 007 . En réponse au journal Dual boot WinXP/Linux 2.6. Évalué à 3.
Je l'ai pas non plus avec Fedora !! (normal, j'ai pas windows).
Youpi !
Qui d'autre ?
Faudrait peut-être comprendre le problème avant de poster des [beep] comme ça.
Si tu as une Debian (ou n'importe quoi d'autre) avec Linux 2.6 + Parted + un dual boot avec win XP et/ou une partition NTFS + un bios pourri + une table de partition écrite en C/H/S alors tu as aussi le bug.
Par contre il est (selon moi) important de communiquer sur ce bug même s'il est rare. En effet, quelques personnes ont refait une installation à partir de zéro en perdant toute leurs données car elles croyaient que "c'était foutu". Pire ! J'ai déjà vu des gens proposer "dd if=/dev/zero of=/dev/hda" pour résoudre ce problème (c'est vrai que ça marche mais c'est brutal).
Enfin, c'est un bug qui est invisible pour ceux qui n'ont pas du Windows. Ce "bug" n'a aucun impacte sur Linux. D'où le fait qu'aucun développeur Linux ne l'ait eu et qu'il est passé un peu inaperçu.
Ceux qui ont installé une Debian avec Linux 2.2 ou 2.4 durant l'installation devrait faire "profile bas" au lieu de rayer leur "petits" camarades. Si la prochaine Sarge avec Linux 2.6 marche sans soucis se sera aussi grace à Mandrake/SuSE/Fedora/... qui auront essuyé les plâtres.
[^] # Re: Version pro à 90 euros
Posté par 007 . En réponse à la dépêche Tests en ligne de SUSE LINUX 9.1. Évalué à -4.
D'ailleurs y a même pas Enlightenment avec transparence alpha et je ne peux pas lire mes DVD avec. Trop naze cette distribution.
[^] # Et alors ?
Posté par 007 . En réponse au journal Dual boot WinXP/Linux 2.6. Évalué à 3.
C'est pour les quelques BIOS qui ne permettent pas de forcer le mode LBA.
[^] # Re: c'est ennuyeux...
Posté par 007 . En réponse au journal Dual boot WinXP/Linux 2.6. Évalué à -2.
[^] # Re: ortho
Posté par 007 . En réponse à la dépêche Test de la Fedora Core 2. Évalué à 0.
RedHat va baser sa version desktop sur la Fedora Core 2 en sortant une version entreprise bientôt (actuellement en test).
Tu peux me donner un lien qui indique que "RedHat va baser sa version desktop sur la Fedora Core 2".
Et où as-tu vu la version test de la prochaine RHEL ?
Les versions test d'RHEL sont publiquement accessibles (ce sont des beta pour faire la différence avec Fedora).
Moi j'ai rien vu. Et la prochaine beta RHEL sera pour Septembre/Octobre 2004 (sortie de la finale début 2005). Or la sortie de FC3 est vaguement prévue pour Octoble 2004. Donc il est possible que la prochaine RHEL soit basée sur FC3 (surtout si Gnome 2.6 et kde 3.2 reste dans FC3).
Donc, faut faire des corrections pour ne pas avancer des choses non prouvées ou donnes moi des liens pour me prouver que j'ai tord.
[^] # Re: performances trés moyennes
Posté par 007 . En réponse à la dépêche Test de la Fedora Core 2. Évalué à 1.
> car depuis la série 8 de la mandrake j'ai souvent était déçu.
> > par contre j'ai viré la fedora pour installer la mandrake 10 official, et là j'ai été agréablement surpris par sa rapidité et surtout par sa stabilité
Pas facile de faire la relation avec les Mandrake précédentes alors que juste avant tu parles de la "lenteur" de FC2.
Peut-être que tu as aussi été surpris de la rapidité par rapport aux autres Mandrake et non par rapport à FC2 ?
Mais désolé, c'est vraiment pas évident à deviner (relis ton post) qu'une fois c'est par rapport à FC2 et juste après c'est par rapport aux autres Mandrake.
> j'ai également écris que la FC2 était lente et que j'étais déçu, ce qui est mon droit.
Je sais pas si tu as remarqué, mais j'ai confirmé cet avis :-).
> ne sois pas agressif
Idem pour toi.
[^] # Re: YAST n'est pas totalement gpl
Posté par 007 . En réponse à la dépêche Tests en ligne de SUSE LINUX 9.1. Évalué à -2.
C'est la même chose pour COPYING, COPYRIGHT.english, COPYRIGHT.german, COPYRIGHT.spanish.
Ou alors il faut faire un procès à SuSE car yast ne respecte pas la licence indiqué par rpm. Très hazardeux.... SuSE pouvant dire que la licence ne s'applique qu'au fichier .spec qui n'est pas dans yast2-packagemanager-2.9.37.tar.bz2.
Si je fouille les sources :
Makefile.in
HAS_GPL_LICENSE = $(shell test -e $(srcdir)/GPL && echo GPL)
Mais il n'y a pas de fichier GPL et il n'y a aucune trace de la licence GPL.
COPYRIGHT_files_gpl = GPL README COPYING COPYRIGHT.english
COPYRIGHT_files_yast = README COPYING COPYRIGHT.english \
COPYRIGHT.french COPYRIGHT.german COPYRIGHT.spanish
extra_COPYRIGHT_files = $(if $(HAS_GPL_LICENSE), $(COPYRIGHT_files_gpl), $(COPYRIGHT_files_yast))
Donc, jusqu'à preuve du contraire, ce n'est pas du GPL. Ou alors je suis une grosse buse.
Pour info, voilà le contenu de README :
This program/library is part of YaST2
See the file COPYRIGHT.english for license terms
Et COPYRIGHT.english est la licence Yast 2 "classique" et pas la GPL.