Le résultat ?
Bien plus de 5000 patchs venant de plus de 600 contributeurs différents ! Et ces statistiques valent uniquement pour la RC1 car à partir de la RC2 il y a eu un nettoyage d'une API (Interface de programmation) du noyau afin de la rendre plus propre et plus logique ce qui a provoqué la modification supplémentaire d'un grand nombre de pilotes (plus de 1100 fichiers nettoyés).
On voit donc que les développeurs Linux restent fermes dans leurs convictions : pas question pour l'instant d'ouvrir une branche 2.7 car le système incrémental actuel fonctionne bien. Pas question, non plus, de faire des compromis sur la propreté des API internes du noyau. Si les mainteneurs de pilote externes ne veulent pas intégrer le noyau, ils devront adapter leur code eux-mêmes.
NdM : On appréciera (ou pas ;-) ) le ton et l'humour inimitable de Linus lors de l'annonce : It's one of those rare "perfect" kernels. So if it doesn't happen to compile with your config (or it does compile, but then does unspeakable acts of perversion with your pet dachshund), you can rest easy knowing that it's all your own d*mn fault, and you should just fix your evil ways. Les nouveautés marquantes du nouveau noyau :
- GFS2, le système de fichier pour cluster qui est concurrent du système OCFS2 d'Oracle, est maintenant disponible. Il améliore radicalement les performances du "vieux" GFS et une liste de ses caractéristiques techniques est disponible sur LWN.
- Ext4 commence le début de son existence dans le noyau en tant que système de fichier expérimental (à ne pas utiliser si vous ne voulez pas prendre de risques). Les nouveautés ont été évoquées dans cette dépêche de LinuxFR.
- eCryptfs est une surcouche au-dessus des autres systèmes de fichiers qui permet de chiffrer/déchiffrer les données de façon souple et intuitive. On peut l'utiliser au cas par cas sans être obligé de chiffrer l'intégralité d'une partition. Cela fonctionne en local mais aussi sur des disques en réseau et les méta-données sont préservées ce qui autorise les copies et les sauvegardes.
- La nouvelle version de Linux propose également le sous-système libata pour les pilotes des disques utilisant la norme PATA (Parallel ATA). Auparavant ces pilotes étaient dans drivers/IDE mais il a été décidé d'utiliser la nouvelle "couche" libata. Cette couche est déjà utilisée pour les nouveaux disques à la norme SATA (Serial ATA) et elle est beaucoup plus propre. Elle a été réécrite entièrement pour améliorer les performances, la gestion des erreurs et le respect des standards. Le fait que les disques SATA et PATA se basent sur libata signifie également une meilleure utilisation du code commun. Dans un souci de compatibilité les anciens pilotes restent utilisés tant que les nouveaux n'ont pas fait la preuve de leur robustesse.
- Dans le domaine du son de nombreux pilotes OSS sont éliminés du noyau (ce qui représente près de 1.8 Mo en moins) au profit des pilotes ALSA.
- Une nouvelle architecture CPU (ATMEL AVR32) est ajoutée dans cette version du noyau Linux. C'est un processeur qui vise le marché de l'embarqué (faible consommation) tout en étant puissant (bon ratio d'instructions par cycle d'horloge).
- La procédure de Read-Copy-Update (RCU) est maintenant préemptible. La procédure RCU permet (en gros) de maximiser les accès en lecture à une donnée. Maintenant le noyau peut "endormir" (préempter) temporairement cette procédure le temps qu'une tâche prioritaire s'exécute. Cette fonction de préemption est très utile pour le temps réel.
- Une API d'annonce des contraintes de latence est maintenant présente. Actuellement, il y a un compromis à faire entre le fait d'économiser du courant (en mettant le processeur dans un mode économie) et le fait de répondre à temps à des évènements (jouer une musique sans coupure). La nouvelle API permet d'améliorer ce compromis énergie/latence en donnant la possibilité aux pilotes d'annoncer au noyau leurs contraintes en terme de latence. Ainsi, par exemple, une webcam indiquera que la latence ne doit pas dépasser 1500 microsecondes si elle ne veut pas perdre d'images. Le noyau ajustera alors la fréquence du processeur pour satisfaire à cette contrainte.
- La fonction de mise en veille (software suspend) est améliorée par l'ajout d'un mode de lecture mémoire asynchrone (ce qui permet d'augmenter la vitesse de réveil de la machine). On note aussi que l'écriture des données en cas de mise en veille se fait maintenant par blocs de 4 Mo et non plus par blocs de 4 Ko. Cela devrait donc également améliorer la vitesse de mise en veille. Plus généralement des fonctions de surveillance des débits en lecture/écriture et de déboggage ont été ajoutées au noyau ce qui constitue une infrastructure solide qui permettra des progrès futurs.
- L'architecture x86-64 supporte maintenant l'ajout à chaud de processeurs et de barrettes mémoire.
- Les systèmes de fichiers formatés en FAT (clés USB et autre) peuvent êtres montés avec l'option -o flush ce qui permet une amélioration des débits au détriment de la robustesse.
- L'algorithme de gestion de la congestion des réseaux TCP est maintenant CUBIC. L'ancien algorithme (BIC) avait été introduit dans le noyau 2.6.7 et CUBIC permet un gain significatif.
- Une infrastructure permettant de "marquer" les paquets réseau est maintenant en place. Afin de répondre au besoin de paquet labeling le sous-système Netlabel a été ajouté au noyau 2.6.19. Cela va permettre de tagguer les paquets de façon cohérente en respectant la norme CIPSO (qui est en passe de devenir un standard des réseaux sécurisés).
- Le support d'un nombre très important de nouveaux périphériques est ajouté au noyau (vidéo, USB, réseau, son, ATA, SCSI...etc etc)
Comme d'habitude la liste très détaillée des nouvelles fonctions et des multiples ajouts est disponible sur la page LinuxChanges du site Kernelnewbies. Cette présentation est maintenant devenue une véritable référence lors de chaque nouvelle sortie du noyau.
Aller plus loin
- Les nouveautés de la version 2.6.19 (24 clics)
- Résumé de l'intégration des patchs partie 1 (4 clics)
- Résumé de l'intégration des patchs partie 2 (2 clics)
- L'annonce sur la LKML (6 clics)
# Cluster
Posté par spotty . Évalué à 9.
[^] # Re: Cluster
Posté par free2.org . Évalué à 1.
http://freshmeat.net/browse/141/
Et un "vieux" site sur les clusters Linux:
http://lcic.org/software.html
Mes 2 centimes...
[^] # Re: Cluster
Posté par andeus . Évalué à 1.
Je recherche un système de fichiers permettant de faire de la réplication, qu'est ce qui existe dans ce domaine ?
Existe t-il un système qui soit VRRP-able voir LVS-able pour faire du fail over et/ou de la répartition de charge ?
[^] # Re: Cluster
Posté par Dragon . Évalué à 9.
Un protocole qui gère des périphériques block (ATA ou scsi) sur le réseau de façon transparente pour le système.
"AoE sends ATA commands over Ethernet frames without the overhead of IP. Communication is done via MAC addresses and is non-routable. Best of all, AoE devices appear as regular block storage. That means you can do with them whatever you would do with local storage. You can manage AoE storage with LVM, create RAID arrays out of your AoE devices, or put a cluster file system on top of them."
cf : http://servers.linux.com/servers/06/06/26/2032206.shtml?tid=(...)
et : http://en.wikipedia.org/wiki/ATA-over-Ethernet
[^] # Re: Cluster
Posté par briaeros007 . Évalué à 4.
L'AoE c'est pour du SAN , pas pour du NAS , donc pas au niveau du fs.
par contre rien n'empeche de faire un NAS sur un SAN qui lui est en AOE :D
/me attend plutot la sortie de zfs HA et de solaris en gpl.
[^] # Re: Cluster
Posté par gde . Évalué à 4.
je ne sais pas si je vais pouvoir t'aider, mais est-ce que t'as regardé du coté de drbd : http://www.drbd.org/ ?
c'est pas exactement un système de fichier mais ça fait de la réplication
[^] # Re: Cluster
Posté par bat13 . Évalué à 2.
http://www.drbd.org/
Ne serait-ce pas quelque chose comme ça que tu cherches ?
[^] # Re: Cluster
Posté par andeus . Évalué à 1.
[^] # Re: Cluster
Posté par IsNotGood . Évalué à 2.
Le site de développement est ici :
http://sources.redhat.com/cluster/
La page "commerciale" de Red Hat (NB : C'est GFS 1) :
http://www.redhat.com/solutions/gfs/
RHEL 5 (sortie fin 2006) aura GFS 2 (en même temps que GFS 1).
La beta 2 est sortie il y a peu :
https://www.redhat.com/archives/rhelv5-announce/2006-Novembe(...)
De la release note :
Fedora a aussi GFS2.
# API d'annonce de contrainte
Posté par Ontologia (site web personnel) . Évalué à 7.
Je pense que c'est un concept très intéressant à généraliser, tout comme la tendance à marquer sémantiquement certains processus comme "desktop" de sorte à leur donner une priorité plus élevé lorsqu'ils traitent un évènement.
Ce genre de modèle devient très intéressant si le compilateur est capable d'évaluer la complexité d'un sous graphe de code.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: API d'annonce de contrainte
Posté par serge D. . Évalué à 1.
- Quand il parle ici : http://lwn.net/Articles/197299/ de (les processeurs modernes supportent des "paliers" de puissance), de quel types de matériels parlent-ils ?
- Est-il possible de généraliser ceci à l'ensemble du sytème GNU/Linux, d'avoir un aperçu de la puissance nécessaire et de régler la puissance de la machine en conséquence ?
- Si cela est possible est-ce réellement économe en énergie et dans quelle proportion ?
Merci
S.
[^] # Re: API d'annonce de contrainte
Posté par Ontologia (site web personnel) . Évalué à 6.
Les processeurs x86 au moins, ça me parait assez évident qu'il possèdent ce genre de fonction
- Est-il possible de généraliser ceci à l'ensemble du sytème GNU/Linux, d'avoir un aperçu de la puissance nécessaire et de régler la puissance de la machine en conséquence ?
Oui et non.
Réussir à généraliser implique de disposer d'une couche de réflexivité assez poussé sur le code.
On fait on a trois voies qu'on peut mixer :
1) On fait des statistiques sur le code, et on règle en conséquence. Sur un lecteur vidéo, en très gros c'est possible parce qu'un flux à décoder tourne toujours autour du même ordre de grandeur.
Dès que tu tombes sur un programmes qui joue aux montagnes russes en terme de consommation avec en plus la problématique de ses autres petis copains qui tournent à côté et qui ont faim eux aussi, là ça risque de devenir ingérable.
2) Le compilateur évalue à la compilation la comlpexité du code. *
En pratique c'est quasiment impossible à faire sur la plupart des langages et certainement en C, à moins qu'une équipe de fou furieux y passe 10 ans.
C'est possible de le faire que sur un langage assez minimaliste qui donc te permet de faire une analyse de flot assez profonde (ie. analyse du graphe du code en analysant toutes les branches possibles du code avec à chaque embranchement le devenir possible de chaque variables, des supputations sur le résultat d'un switch, etc...).
Bref avec 4 Go de consommation mémoire pour compiler 2000 lignes de code (la combinatoire est exponentielle), ça monte très vite..
Avec un moteur pareil, tu peux embarquer dans le code une estimation, un ordre de grandeur de la complexité de ton algo. Tiens celui-ci est un o(n²), celui-ci un o(e^n) (aïe..).
Là le sheduleur calcul rapidement (on lui donne n) et affecte la consommation en conséquence
3) au début t'es à 50 % de la fréquence. Le décodeur vidéo te dit "il me faut assez de ressource pour avoir fini de décoder mon image dans 50 ms". Tu donne la main au bout de code en question. 30 ms passe pas fini. Tu augmente la fréquence de 25 %.
On est à 42 ms. toujours pas fini.
Tu montes à 100 % de puissance
48 ms, il a fini
C'est bon tu redescend à 50 % de fréquence.
C'est une pure supposition hein.
- Si cela est possible est-ce réellement économe en énergie et dans quelle proportion ?
Dans la même proportion de gain de consommation en fonction de la fréquence de ton processeur, de sa charge, etc...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: API d'annonce de contrainte
Posté par Nicolas Boulay (site web personnel) . Évalué à 10.
P = K*F*V²+S
K est un facteur lié à la téchnologie (capa parasite,...)
F est la fréquence
V la tension d'alim
S la fuite de courant
Pour diminuer le courant en idle, tu coupe la clock et tu réduit le terme de conso dynamique.
Tu peux même éteindre une zone complète. Mais "rallumer" prend du temps, le temps que le régulateur se mettent à la bone valeur.
Une fois que l'on coupe tout quand il n'y a rien à faire, il reste à baisser la conso quand le processeur est actif.
Si une tache prends 10 000 coup d'horloge, baisser la fréquence ne change rien. L'énergie pour la tâche est la même (sauf si S >> KFV² dans ce cas, c'est encore pire).
L'idée est alors de baisser V en même temps que F, dans ce cas on y gagne (S baisse aussi).
La tache sera plus lente mais moins énergivore. Par contre, le problème est la latence pour changer de mode quand le besoin de puissance arrive. D'ou l'idée de gérer les latences dans une API j'imagine.
"La première sécurité est la liberté"
[^] # Re: API d'annonce de contrainte
Posté par gpe . Évalué à 2.
Parce que je bosse sur un chip incluant un ARM946 + DSP et pour économiser l'énergie on baisse uniquement la clock cpu et/ou dsp et comme il n'y a pas de latence lors du changement je ne pense pas qu'il y ait adaptation de tension?
[^] # Re: API d'annonce de contrainte
Posté par dguihal . Évalué à 4.
http://www.amd.com/us-en/assets/content_type/DownloadableAss(...)
en particulier la phrase :
est explicite concernant ta question.
Donc oui il peut y avoir un ajustement de la tension d'alimentation également, ça dépend de l'architecture du CPU. Ceci est d'autant plus vrai que le fait de baisser la fréquence permet d'utiliser son CPU a une tension moindre (en gros c'est l'inverse de l'overclocking)
[^] # Re: API d'annonce de contrainte
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Moi je travail sur une archi ARM11+DSP+GPU et la gestion d'énergie est super complexe.
"La première sécurité est la liberté"
[^] # Re: API d'annonce de contrainte
Posté par reno . Évalué à 3.
Je pense que ça dépend de ce que veut dire le 'quand ton processeur fait quelque-chose'.
Certes si tu considère qu'une tache fait X cycles que ces cycles soient fait a une fréquence ou une autre, l'énergie consommée sera identique, mais ça ce n'est vrai que dans le cas assez rare ou ton application est purement limitée par le CPU.
En général un CPU qui fait quelque-chose attend souvent la mémoire, les disques, etc, et là diminuer la fréquence devrait permettre d'économiser de l'énergie, non?
Je ne suis pas un expert en la matière..
[^] # Re: API d'annonce de contrainte
Posté par Jul (site web personnel) . Évalué à 5.
Si tu joues uniquement sur la fréquence, tu ne gagne rien sur la consomation quand ton processeurs fait quelques choses.
Moins d'instructions, moins de dépenses. Par contre, tu changes rien en consommation PAR instruction
Donc tu as tort, et tu as raison.
Les FET ont en fait un aspect capacitif non négligeables => dont à chaque chargement, déchargement on met/retire de la capacité dedans, mais les SemiCondcuteurs restent conducteurs (dans les conditions où l'on travaille) donc à chaque décharge on a des pertes resistives, proportionnelles au carré de la tension.
I = dq/dt et la charge est q=cV, donc moins on charge, moins haute est la perte.
donc il faut bien modifier la fréquence pour diminuer la consommation d'énergie (moins d'instruction, moins de courant), mais aussi la tension. (plus on va vite, plus pour charger les drains il faut augmenter la tension). On voit intuitivement que diminuer tension et fréquence doivent donner des gains plus que linéaire.
Mais bon il faut pas trop baisser sinon on a plus de signal nominal nécessaire pour être fiable.
et peut être que tu as ni tort ni raison
Tes différents composants ont des couples fréquences/tension de fonctionnements optimales différentes. Et il n'y a pas de méthodes simples pour déterminer à tous les coups sur quelles composantes s'aligner.
Donc au final, comme la physique théorique est incapable de te sortir une explication simple, si tu veux vraiment savoir comment diminuer la consommation d'énergie : tu plonge le circuit dans un bain, et tu analyse les pertes calorique en fonction des paramètres pour différentes utilisation qui miment ton fonctionnement attendu de ta puce :) Tu fais un relevé T=f(Fréquence, Tension, type applicatif), tu fais l'union des bassins qui sont optimums à 80% si ça se recouvre tu choisis à la réunion, sinon, t'es pas encore arrivé :) mais sur la bonne voie.
Hack da world avec un couteau suisse !
# Et pour les serveur Dell...
Posté par Mr F . Évalué à 5.
[^] # Re: Et pour les serveur Dell...
Posté par ashram4 . Évalué à 4.
[^] # Re: Et pour les serveur Dell...
Posté par symoon . Évalué à 3.
[^] # Re: Et pour les serveur Dell...
Posté par ashram4 . Évalué à 2.
En plus les interfaces réseaux n'apparaise pas dans le répertoire /dev.
le passage d'un noyau 2.4.?? à un 2.6.17 udev n'a rien changé pour mon problème de chargement carte/interface.
[^] # Re: Et pour les serveur Dell...
Posté par ookaze . Évalué à 5.
Je change l'attribution de nom de mes interfaces avec Udev, et il décide en fonction de la MAC address (sensible à la casse depuis peu) chez moi.
Je ne vois pas où est le problème, tu peux même scripter la détermination des MAC address si tu veux, avant de les passer à udev.
[^] # Re: Et pour les serveur Dell...
Posté par ashram4 . Évalué à 0.
[^] # Re: Et pour les serveur Dell...
Posté par ribwund . Évalué à 3.
sinon la plupart des distros font ce genre de truc par defaut (ils fixent le nom de l'interface a l'install)
[^] # Re: Et pour les serveur Dell...
Posté par ashram4 . Évalué à 1.
[^] # Re: Et pour les serveur Dell...
Posté par nodens . Évalué à 2.
J'ai découvert complètement par hasard hier comment ça marchait sous debian en cherchant pourquoi j'avais eth0 et eth2 avec seulement 2 interfaces; en fait il s'est avéré que le nombre d'interfaces a changé entre l'install et la suite, donc tout s'explique (et un grep "eth[[:digit]]" m'a permis de trouver le script dans /etc/udev) ;)
[^] # Re: Et pour les serveur Dell...
Posté par ookaze . Évalué à 2.
KERNEL=="eth*", SYSFS{address}=="MAC_sensible_casse", NAME="nom_interface_max_8_lettres"
Je ne saisplus quel paquet oblige à limiter le nom de l'interface réseau à 8 caractères max.
Je lance udev très tôt dans la séquence de boot, donc pas de souci.
Sinon, si qqch monte une interface avant qu'udev modifie le nom, tu ne peux plus le changer et tu restes avec eth*, si ton driver est dans le noyau.
[^] # Re: Et pour les serveur Dell...
Posté par Michel Pastor . Évalué à 3.
[^] # Re: Et pour les serveur Dell...
Posté par Mr F . Évalué à 1.
1. Cela n'empêche pas le problème à l'installation
2. Il faut le gérer manuellement ou via un script
3. Il faut faire du cas par cas/de la détection de situation.
4. Ce n'est pas plus mal, au final, de se passer d'une couche et que le kernel agisse comme il le devrait, affecter eth0 à la première interface...
# Anglais
Posté par golum . Évalué à 9.
Autant l'anglais technique ne me pose pas trop de pb autant je ne capte jamais rien à ce genre de tournures plein de sous-entendus.
Quelqu'un se dévoue ?
[^] # Re: Anglais
Posté par nanard . Évalué à 8.
Je m'y risque:
En gros il dit que le noyau a atteinds un super niveau de maturité et que si tu a des erreurs de fonctionnement aprés avoir recompilé un noyau ou qu'il ne compile pas, c'est que t'est trop c*n pour utiliser un pc .
Allez tous vous faire spéculer.
[^] # Re: Anglais
Posté par Jean-Philippe (site web personnel) . Évalué à 10.
"It's one of those rare "perfect" kernels. So if it doesn't happen to compile with your config (or it does compile, but then does unspeakable acts of perversion with your pet dachshund), you can rest easy knowing that it's all your own d*mn fault, and you should just fix your evil ways."
C'est un des ces rares noyaux "parfaits". Donc, si vous n'arrivez pas à compiler avec votre config (ou si cela compile, mais ensuite donne lieu à des actes ["non énoncables"] de perversion avec votre teckel), vous pouvez [facilement ?] savoir que c'est entièrement votre faute, et que vous devriez juste corriger vos comportements diabliques.
[^] # Re: Anglais
Posté par xenon_hs (site web personnel) . Évalué à -4.
[^] # Re: Anglais
Posté par philippe G. . Évalué à 2.
L'est taquin Linus ;-)
[^] # Re: Anglais
Posté par boubou (site web personnel) . Évalué à 10.
C'est un des ces rares noyaux "parfaits". Donc, si d'aventure ce noyau ne compile par sur votre configuration (ou s'il compile, mais s'adonne ensuite à d'indicibles actes de perversion avec votre teckel de compagnie), vous pouvez être certain que c'est entièrement de votre putain de faute : vous devriez simplement arrêter de mal vous comporter.
[^] # Re: Anglais
Posté par alf . Évalué à 6.
Mais bon, on ne va pas trop chipoter sur un tirade pareille non plus ;)
[^] # Re: Anglais
Posté par gpe . Évalué à 10.
[^] # Re: Anglais
Posté par davux (site web personnel) . Évalué à -2.
[^] # Re: Anglais
Posté par Aldoo . Évalué à -5.
[^] # Re: Anglais
Posté par alf . Évalué à 10.
"unspeakable" -> je tenterais bien un "innomables".
Pareil pour "evil", "diabolique" me semble un peu fort. "Devil" siginifie le diable, mais "evil" est plus "mauvais", "malsain"...
D'où ma proposition, en reformulant un petit peu :
Il y a juste le "d*mn" que je ne sais pas encore comment formuler...
[^] # Re: Anglais
Posté par dguihal . Évalué à 4.
[^] # Re: Anglais
Posté par ewasx . Évalué à 6.
[^] # Re: Anglais
Posté par arN34 . Évalué à 5.
[^] # Re: Anglais
Posté par Elghinn . Évalué à 1.
« c'est un de ces rares noyaux »
C'est étonnant que personne ait vu la faute après plusieurs copié/collé.
[^] # Re: Anglais
Posté par Jean-Philippe (site web personnel) . Évalué à 2.
[^] # Re: Anglais
Posté par Smarter . Évalué à 6.
Que je traduirais par:
:)
[^] # Re: Anglais
Posté par vavil . Évalué à 3.
# libata
Posté par karmatronic . Évalué à 1.
vais je reussir á recuperer le dma sur mon graveur dvd avec ce 2.6.19 , telle est la question ......?
vous le saurez dans la journee.....:)
[^] # Re: libata
Posté par alphacc . Évalué à 4.
Histoire qu'on puisse verifier les compteurs smart facilement et donc l'etat de nos disques.
[^] # Re: libata
Posté par ookaze . Évalué à 3.
Il y a juste une option à ajouter pour qu'il aille chercher les infos par libata.
[^] # Re: libata
Posté par Anthony Bourguignon (site web personnel) . Évalué à 2.
[^] # Re: libata
Posté par Grégory SCHMITT . Évalué à 5.
Je tourne sous Fedora 6. Chipset Intel ICH6. Je possède un disque dur au format SATA, branché sur le port SATA de la carte mère, ainsi que deux lecteurs DVD IDE/ATAPI branchés en maître-esclave sur l'unique port IDE de la carte-mère. Pas d'adaptateur ou de carte externe.
Pour l'instant, tout fonctionne. J'ai eu un peu d'appréhension quand j'ai décoché toute la section ATA/IDE de la configuration, puis activé la gestion SATA et PATA de la libata. Ça s'est fait très facilement, beaucoup plus à mon sens que la configuration de l'ancienne section puisqu'il n'a suffit que de deux options à activer, à savoir le driver SATA pour le disque dur, et le PATA pour mes deux dvdroms. Tout a été compilé en module - rien dans le kernel en lui-même.
À noter que la gestion SATA est censée être stable (prod), en revanche la gestion PATA est toujours expérimentale. Certains chipsets sont encore qualifiés d'extrêmement expériemental d'ailleurs. Les classiques et répandus chipsets Intel et VIA ont l'air d'être stables - pas de mise en garde particulière.
Mon disque dur est resté en /dev/sda - logique.
Mes deux DVDs ont été renommés en scd0 et scd1 (la norme scsi me semble-t'il...), auparavant hda et hdb.
Grâce à udev, les liens symboliques dans /dev (dvd, dvdwriter et compagnie...) repointent automatiquement vers scd0 et scd1. Pratique.
J'ai juste changé mon fstab et tout marche impec'.
Quelques petits problèmes cependant, mineurs à mon sens:
- nero 2.1.0.3 ne les détecte plus, à cause des permissions. Pensez à ajuster vos règles udev si ce n'est déjà pour pouvoir graver en mode utilisateur, ou alors jouez à coup de chown sur sg*.
- j'ai pas encore essayé hdparm, donc impossible de donner l'état des performances. Quid de l'UDMA ? Comment faire pour ralentier mes deux dvdroms pour leur éviter de tourner à toute berzingue, et donc répliquer hdparm -E ? Mystère... je cherche.
Le GROS point auquel il faut faire attention, c'est de passer son disque dur qui contient la racine - il faut alors changer son fstab avant redémarrage, sous peine de se voir coincé au prochain ! Les solutions à mettre en place:
- peut-être qu'en mettant plusieurs lignes dans to fstab pour désigner la partition racine...
- utiliser les labels, mais personnellement je n'aime pas...
Donc pour l'instant, que du positif - tout me semble nettement plus harmonieux, entre disques durs, lecteurs dvds, graveurs externes sur USB...
[^] # Re: libata
Posté par karmatronic . Évalué à 1.
comme device scsi
[^] # Re: libata
Posté par briaeros007 . Évalué à 5.
La véritable solution est... NE DELETEZ PAS VOTRE ANCIEN NOYAU !!!
ca à l'air tout con, mais maintenant n'importe quel boot manager digne de ce nom permet d'afficher une liste de noyau sur lequel booter. Rien de plus simple dans ce cas de juste rajouter une entrée, et de laisser l'ancien le temps que tout marche aux petits oignons.
[^] # Re: libata
Posté par Anthony Bourguignon (site web personnel) . Évalué à 2.
Mais de toute façon, c'est toujours une bonne idée de garder son ancien noyau au cas où.
[^] # Re: libata
Posté par Mjules (site web personnel) . Évalué à 4.
[^] # Re: libata
Posté par djibb (site web personnel) . Évalué à 5.
Je ne reviendrai a Lilo pour rien au monde. Ne serait-ce que qaund tu as 2-3 linux a gérer dans le boot loader.
[^] # Re: libata
Posté par ʭ ☯ . Évalué à 3.
essaye 'eject -x' ça fait la même chose, et au chargement du CD svp ;-)
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: libata
Posté par karmatronic . Évalué à 1.
pour ceux que ça interesse , je pense que dans des cas ou vraiment le dma ne veut pas fonctionner (ie malgré libata en module avec l option atapa.enabled=1), essayer de recompiler avec un maximum en modules (donc initrd pour les modules du chipset ,...)
@+
[^] # Re: libata
Posté par phoenix (site web personnel) . Évalué à 3.
Les disques dur IDE deviendront maintenant du scsi ? sd*
Ne serait-il pas mieux de prendre une nouvelle norme de nommage ? par exemple : la*
Enfin moi j'aimais bien quand IDE = hd et SCSI = sd
# Une vraie question
Posté par Jeanuel (site web personnel) . Évalué à 5.
Je suis certainement un inculte qui réveille sans le savoir de vieux trolls, mais pourquoi le noyau s'occupe-t-il du réseaux ? C'est vraiment son travail ?
[^] # Re: Une vraie question
Posté par Prosper . Évalué à -1.
[^] # Re: Une vraie question
Posté par neologix . Évalué à 4.
Dommage que le Hurd soit mort, enfin y'a apparemment Minix qui vit sa vie.
[^] # Re: Une vraie question
Posté par briaeros007 . Évalué à 2.
[^] # Re: Une vraie question
Posté par Jul (site web personnel) . Évalué à 2.
[^] # Re: Une vraie question
Posté par Moonz . Évalué à 2.
[^] # Re: Une vraie question
Posté par Pierre Tramonson . Évalué à 10.
[^] # Re: Une vraie question
Posté par Pascal . Évalué à 10.
Qu'est-ce qui techniquement empeche d'implementer les protocoles TCP, IP, voire de couche 2 dans une librairie tournant en user-space??? Rien.
Mais pour répondre à ta question, je crois que l'intégration totale des couches réseaux dans le noyeau jusqu'à TCP a une raison historique.
En effet, Linux se veut un clone d'UNIX et historiquement TCP a toujours été implémenté dans les noyeaux UNIX. D'ailleurs, l'API socket est présente dans le norme POSIX, qui jusqu'à maintenant fait référence.
[^] # Re: Une vraie question
Posté par reno . Évalué à 3.
Techniquement rien bien sur, mais par contre, c'est quand même loin d'être évident pour les performances (augmentation du changement de contexte).
[^] # Re: Une vraie question
Posté par ribwund . Évalué à 6.
[^] # Re: Une vraie question
Posté par reno . Évalué à 1.
Dans "Reconsidering network channels" http://lwn.net/Articles/192767/ il y a "It is an amazing toy. But I see nothing, which could promote its status to practical.".
De manière plus anecdotique, je me demande ce qui se passe quand tu essaye de te connecter a une application avec un processus de 300Mo ou plus qui est swappé sur le disque.
[^] # Re: Une vraie question
Posté par Pascal . Évalué à 1.
Rien...
En effet, dans le cas que tu décris, l'application doit séverement ramer, alors si les couches TCP ou IP rament aussi, je ne suis pas sur que ca empire beaucoup les choses.
[^] # Re: Une vraie question
Posté par reno . Évalué à 1.
Donc cela change quelquechose, même si en pratique je ne pense pas que ce soit un problème, cela retarde juste un peu l'établissement de la connection.
[^] # Re: Une vraie question
Posté par Guillaume Knispel . Évalué à 2.
T'as jamais fait trasher une box comme un malade toi :)
[^] # Re: Une vraie question
Posté par reno . Évalué à 2.
[^] # Re: Une vraie question
Posté par CoinKoin . Évalué à 2.
Or la simplicité implique généralement la robustesse, ça, même Tannenbaum le proclame... D'où un réel intérêt à laisser les piles réseaux dans les noyaux.
[^] # Re: Une vraie question
Posté par Prae . Évalué à 2.
# Speedstep Centrino
Posté par Juke (site web personnel) . Évalué à 2.
Quelqu'un sait il si le noyau va un jour integrer les patch pour le speedstep centrino sur les dothan ?
cf http://linuxfr.org/comments/774694.html#774694
[^] # Re: Speedstep Centrino
Posté par IsNotGood . Évalué à 10.
# libata et les noms de devices
Posté par Aurélien Bompard (site web personnel) . Évalué à 7.
# Modèle de développement
Posté par neologix . Évalué à 6.
Je suis désolé, mais je trouve le modèle de développement actuel MERDIQUE.
Je n'ai jamais eu autant de problèmes: depuis la version 2.6.17:
-si j'utilise le pilote AC97 en module, il ne se charge pas 1 fois sur 2. En dur, ça passe. J'ai envoyé plusieurs mails aux mainteneurs, pas de réponse
-une fois sur 10, le démarrage bloque à la détection des périphériques usb. Ca ne me l'avait jamais fait avant
-la version de bcm43xx du 2.6.18 plantait la machine au bout de quelques minutes. Là, je viens d'essayer le 2.6.19, et je me mange un watchdog au bout de quelques minutes. Ca fait deux fois de suite qu'ils packagent une version instable dans cette branche "-stable".
Alors, faudrait qu'ils arrêtent de se masturber en disant que le noyau et son modèle de développement actuel sont bons, c'est faux.
Qu'on fasse une branche de développement pour l'expérimentation, et une branche stable pour cux qui veulent bosser.
[^] # Re: Modèle de développement
Posté par patrick_g (site web personnel) . Évalué à 3.
[^] # Re: Modèle de développement
Posté par taratatatata . Évalué à 9.
MAIS AUCUNE DISTRO NE L'UTILISE, OLOLOL.
Ubuntu Long Term Support utilise le 2.6.15.
Red Hat Enterprise Linux 5 utilisera le 2.6.17.
La debian etch utilisera le 2.6.17 ou peut-être 2.6.18.
Mandriva utilise le 2.6.17.
Il n'y a que Novell qui est tout seul avec son 2.6.16 pour les SLED/SLES.
"In December of 2005, Adrian Bunk announced his intention to maintain the 2.6.16 kernel indefinitely, maintaining it much the same as the 2.4 kernel is maintained for as long as it is used and patches are contributed."
Pauvre gars. Huhu.
[^] # Re: Modèle de développement
Posté par ribwund . Évalué à 3.
[^] # Re: Modèle de développement
Posté par djibb (site web personnel) . Évalué à 8.
[^] # Re: Modèle de développement
Posté par ʭ ☯ . Évalué à 2.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Modèle de développement
Posté par Pierre Jarillon (site web personnel) . Évalué à 1.
Si on se réfère à la version 2006, l'essentiel des mises à jour ont été mises en ligne très rapidement aussi.
Je suis d'accord avec toi, il ne faut pas trop se presser surtout quand les changements sont importants. J'ai installé des Mandrake 9.2.1, la dernière avec le noyau 2.4 : l'une d'elles a fait un uptime de 450 jours et l'autre fonctionne toujours. C'était une version Club qui intégrait toutes les corrections connues après quelques mois d'exploitation de la 9.2.
Mandriva devrait sortir en octobre la version N et en mars la version N.1 bien débuggée que l'on pourrait qualifier de professionnelle. Comme c'est la distribution qui a actuellement le noyau le plus à jour (http://linuxfr.org/comments/780250.html#780250) elle pourrait alors faire un tabac.
[^] # C'est entièrement de ta faute
Posté par TemPi . Évalué à 10.
[^] # Re: Modèle de développement
Posté par iug . Évalué à 2.
-une fois sur 10, le démarrage bloque à la détection des périphériques usb. Ca ne me l'avait jamais fait avant
chémoiçamarchait
Tu ne serais pas le malheureux propriétaire d'un chipset mal documenté (ATI, nvidia) avec des périphs mal documentés deussus (wifi, carte graphique) ?
[^] # Re: Modèle de développement
Posté par neologix . Évalué à 2.
Mais le problème n'est pas vraiment là, puisque ça marchait avant.
Il s'agit de régressions, et apparemment tout le monde s'en fout. Quand je regarde la taille des changelogs, j'ai vraiment très peur pour le futur. Comment peut-on prétendre stabiliser un noyau qui a 3Mo de changelog en 1 mois? Comment peut-on faire confiance à des gens pour qui le travail de stabilisation est laissé aux distributions?
Enfin, étant donné la complexité croissante des périphériques, donc des pilotes, et que la plupart des gens qui écrivent les pilotes connaissent le matos mais pas grand chose à la programmation en espace noyau, et que Linux n'est pas un micro-noyau (donc la moindre erreur au niveau du pilote plante la bécane), je pense qu'on va dans le mur.
Enfin, ce n'est que mon avis, hein.
[^] # Re: Modèle de développement
Posté par ribwund . Évalué à 3.
tsss, si tu reportes pas ca risque pas de changer, sinon y'a des gens qui trackent les regressions plutôt bien:
http://groups-beta.google.com/groups/search?q=regressions&am(...)
[^] # Re: Modèle de développement
Posté par scullder . Évalué à 3.
Ca m'est arrivé avec les changements sur l'IOMMU dans le 2.6.18.
# FAT et "-o flush"
Posté par tgl . Évalué à 4.
Tel que je comprends la description du patch, ce n''est que comparé à un "-o sync" que le "-o flush" peut être qualifié de plus rapide et moins robuste :
http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6(...)
Mais ça reste plus sûr que l'absence d'option (qui ne flush que de temps à autre, ou sur sync explicite et unmount), et moins rapide évidemment. Une espèce de compromis donc...
[^] # Re: FAT et "-o flush"
Posté par _Hitek_ (site web personnel) . Évalué à 3.
[^] # Re: FAT et "-o flush"
Posté par Pascal Terjan (site web personnel) . Évalué à 6.
Si je dis mount -o plop, c'est le kernel qui se plaint dans ses logs :
EXT3-fs: Unrecognized mount option "plop" or missing value
# Evolution fulgurante
Posté par Franck Charpentier . Évalué à 2.
[^] # Re: Evolution fulgurante
Posté par neologix . Évalué à 10.
[^] # Re: Evolution fulgurante
Posté par lejocelyn (site web personnel) . Évalué à 1.
[^] # Re: Evolution fulgurante
Posté par Franck Charpentier . Évalué à 0.
[^] # Re: Evolution fulgurante
Posté par Clenche . Évalué à 1.
# Bootsplash
Posté par dguihal . Évalué à 3.
Il semble en effet que le kernel n'aie plus de fichier <linux/config.h>
le patch pour compiler les fichiers :
drivers/video/bootsplash/bootsplash.c
drivers/video/bootsplash/decode-jpg.c
drivers/video/bootsplash/render.c
ressemble a ca
-#include <linux/config.h>
+#include <linux/version.h>
+
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,18)
+#include <linux/utsrelease.h>
+#endif
+
+#if LINUX_VERSION_CODE <= KERNEL_VERSION(2,6,18)
+#include <linux/config.h>
+#else
+#include <linux/autoconf.h>
+#endif
+
Au moins ca compile maintenant, je vous tiendrai au courant si ca fonctionne
Attention ceci n'est pas officiel et entierement de mon fait. Je me suis inspiré de de ceci : http://lists.terrasoftsolutions.com/pipermail/mol-general/20(...) )
[^] # Re: Bootsplash
Posté par dguihal . Évalué à 1.
Par contre il me reste les pilotes rt2500 a faire compiler
[^] # Re: Bootsplash
Posté par Brice Goglin . Évalué à 2.
Pour utsrelease.h, il suffit d'inclure version.h puis ensuite de tester si UTS_RELEASE est défini et si ce n'est PAS le cas, inclure utsrelease.h.
Pour autoconf/config.h, il vaut mieux regarder si AUTOCONF_INCLUDED est défini (il l'est au début de autoconf.h, qui est inclu automatiquement depuis plusieurs noyaux), et si ce n'est PAS le cas, inclure config.h a la main.
[^] # Re: Bootsplash
Posté par dguihal . Évalué à 0.
Cependant je dirai que pour un noyau < 2.6.19 le pach bootsplash existe déjà et qu'il suffit de prendre la version existante.
Je te remercie pour tes remarques quand même, ça va m'aider pour faire compiler le pilote RT2500
[^] # Re: Bootsplash
Posté par Jean-Yves LENHOF (site web personnel) . Évalué à 1.
http://alioth.debian.org/projects/splashy/
# UML ?
Posté par spotty . Évalué à 0.
http://user-mode-linux.sourceforge.net/index.html
Donc on a déjà Xen, GFS2, user-mode-linux :-)
# Reiser4
Posté par GEDsismik (site web personnel) . Évalué à 1.
Me trompe-je ?
[^] # Re: Reiser4
Posté par tuxsmouf . Évalué à 2.
[^] # Re: Reiser4
Posté par Boa Treize (site web personnel) . Évalué à 4.
[^] # Re: Reiser4
Posté par Pascal . Évalué à 1.
[^] # Re: Reiser4
Posté par Pol' uX (site web personnel) . Évalué à 1.
J'espère que les policiers seront compréhensifs et qu'il lui laisserons un accès internet !
Adhérer à l'April, ça vous tente ?
[^] # Re: Reiser4
Posté par André Rodier . Évalué à 3.
[^] # Re: Reiser4
Posté par achil . Évalué à 6.
# Puisque personne ne se décides
Posté par dguihal . Évalué à -9.
\o/
bon OK -----------> []
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.