Articles précédents : Logiciel
- [14] K3DSurf 0.6.0 : Mise à jour majeure
- [32] Hula devient un projet communautaire
- [90] Projet Ryzom Libre
- [80] aMSN 0.96
- [24] dblatex : Docbook XML -> LaTeX -> PDF
- [36] PeerTV pour Linux
- [24] MakeHuman 0.9 : modeleur de corps humains
- [18] Le Projet Firebird publie Firebird 2.0
- [13] Une nouvelle version des pilotes pour imprimante Samsung
- [2] pyctd, un outil de visualisation et de modification du suivi de connexions
Liens connexes
- Les nouveautés de la version 2.6.19 (3285 hits)
- Résumé de l'intégration des patchs partie 1 (401 hits)
- Résumé de l'intégration des patchs partie 2 (271 hits)
- L'annonce sur la LKML (486 hits)
Dépêche modérée par
Dépêche éditée par
Logiciel : Nouvelle version 2.6.19 du noyau Linux
Posté par patrick_g (page perso, ). Modéré le 30 novembre 2006.
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.
![[en]](../../../images/en.png)
Les nouveautés de la version 2.6.19 (3285 hits)-
Résumé de l'intégration des patchs partie 1 (401 hits)
-
Résumé de l'intégration des patchs partie 2 (271 hits)
-
L'annonce sur la LKML (486 hits)
> Lire la dépêche (115 commentaires, moyenne: 3,4).
- 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.
Cluster
Je vois avec plaisir que le kernel de Linux s'implique de plus en plus dans la technologie des clusters, en revanche je n'ai pas trouvé de site qui centralisait l'information sur ces cluster, même pas de HOWTO à part beowulf. Je ne connais même pas le nom des outils pour utiliser GFS2 , j'ai l'impression qu'il y a comme manque à cet endroit
-
[^]Re: Cluster
Posté par free2.org (page perso, ) le 30/11/2006 à 11:53. (lien). Évalué à 1.Freshmeat bien-sûr
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 () le 30/11/2006 à 12:28. (lien). Évalué à 1.En gros par rapport à NFS ça apporte quoi ?
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 () le 30/11/2006 à 12:44. (lien). Évalué à 9.ATA over ETHERNET
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 () le 30/11/2006 à 18:49. (lien). Évalué à 4.euhh ...
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.--
Subete ga wakatta toki…watashi ga anta wo korosu.
-
-
[^]Re: Cluster
Posté par Guillaume Douté (page perso, ) le 30/11/2006 à 12:46. (lien). Évalué à 4.Je recherche un système de fichiers permettant de faire de la réplication, qu'est ce qui existe dans ce domaine ?
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 IsNotGood () le 30/11/2006 à 18:03. (lien). Évalué à 2.> Je ne connais même pas le nom des outils pour utiliser GFS2
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 :
GFS2. GFS2 is an evolutionary advancement based on the GFS file system. While fully functional, GFS2 has not yet completed all required qualification testing.
Fedora a aussi GFS2.
API d'annonce de contrainte
C'est marrant j'y avais pensé il y a quelques mois, mais pas pour Linux et pas pour des raisons d'économies d'énergie.
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.
-
[^]Re: API d'annonce de contrainte
Posté par serge D. () le 30/11/2006 à 13:14. (lien). Évalué à 1.Je ne suis pas sûr de comprendre l'étendue de cette API.
- Quand il parle ici : http://lwn.net/Articles/197299/ deModern processors support a number of power states...
(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 (page perso, ) le 30/11/2006 à 14:21. (lien). Évalué à 6.(les processeurs modernes supportent des "paliers" de puissance), de quel types de matériels parlent-ils ?
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...-
[^]Re: API d'annonce de contrainte
Posté par Nicolas Boulay () le 30/11/2006 à 16:34. (lien). Évalué à 10.Le principe d'économie d'énergie est simple. C'est basé sur l'équation :
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.-
[^]Re: API d'annonce de contrainte
Posté par gpe () le 30/11/2006 à 17:19. (lien). Évalué à 2.Est-ce toujours vrai?
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 () le 30/11/2006 à 17:26. (lien). Évalué à 4.Un exemple pour AMD avec le powernow :
http://www.amd.com/us-en/assets/content_type/DownloadableAss(...)
en particulier la phrase :
AMD PowerNow! technology controls your notebook’s level of processor performance
automatically, dynamically adjusting the operating frequency and voltage many times per second,
according to the task at hand.
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 () le 30/11/2006 à 18:54. (lien). Évalué à 4.Si tu joues uniquement sur la fréquence, tu ne gagne rien sur la consomation quand ton processeurs fait quelques choses.
Moi je travail sur une archi ARM11+DSP+GPU et la gestion d'énergie est super complexe.-
[^]Re: API d'annonce de contrainte
Posté par reno () le 06/12/2006 à 20:06. (lien). Évalué à 3.>Si tu joues uniquement sur la fréquence, tu ne gagne rien sur la consomation quand ton processeurs fait quelques choses.
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 (page perso, ) le 15/12/2006 à 18:15. (lien). É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...
On notera l'inclusion du patch de Matt Domsch permettant de réinverser l'ordre des interfaces réseaux des nouveaux serveurs de Dell (série 9) afin qu'elles soient enfin dans le bon sens (eth0 correspondant au label 1 et eth1 au label 2).
-
[^]Re: Et pour les serveur Dell...
Posté par ashram4 () le 30/11/2006 à 12:41. (lien). Évalué à 4.ifname, ifrename ça ne permet pas de réglé ton problème ?
-
[^]Re: Et pour les serveur Dell...
Posté par symoon (page perso, ) le 30/11/2006 à 14:09. (lien). Évalué à 3.ou peut-être plus moderne, udev ?
-
[^]Re: Et pour les serveur Dell...
Posté par ashram4 () le 30/11/2006 à 14:25. (lien). Évalué à 2.il faut bien lui spécifier quelque part quelle carte sur quelle interface? udev c'est juste un système de gestion "dynamique" du repertoire /dev
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 () le 30/11/2006 à 14:56. (lien). Évalué à 5.Que veux-tu dire ?
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 () le 30/11/2006 à 15:07. (lien). Évalué à 0.tu as un lien sous la main? remarque c'est pas urgent je viens d'apprendre qu'on m'expédie une semaine en Corée. Je vais privilégié mon sommeil plutôt que mon PC pour les 2 prochains jours.
-
[^]Re: Et pour les serveur Dell...
Posté par ribwund () le 30/11/2006 à 18:23. (lien). Évalué à 3.http://www.reactivated.net/writing_udev_rules.html#example-n(...)
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 () le 30/11/2006 à 21:20. (lien). Évalué à 1.merci, ça fait peu de temps que j'utilise un kernel 2.6 ça excuse un peu mon ignorance sur le sujet.
-
[^]Re: Et pour les serveur Dell...
Posté par nodens (page perso, ) le 01/12/2006 à 07:07. (lien). Évalué à 2.En même temps c'est pas toujours très bien documenté.
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) ;)--
Clément Hermann (nodens)
- "L'air pur ? c'est pas en RL, ça ? c'est pas hors charte ?"
Jean in L'Histoire des Pingouins, http://tnemeth.free.fr/fmbl/linuxsf/
GPG : pgp.mit.edu - 0xEBD1399D
-
[^]Re: Et pour les serveur Dell...
Posté par ookaze () le 01/12/2006 à 10:17. (lien). Évalué à 2.Je dois avoir des lignes de ce genre dans mon /etc/udev/rules/10-local.rules :
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 () le 01/12/2006 à 14:47. (lien). Évalué à 3.Tu peux même si le driver est en dur dans le noyau il suffit que l'interface soit "down" pour pouvoir changer son nom.
-
-
-
-
-
-
-
[^]Re: Et pour les serveur Dell...
Posté par Mr F (page perso, ) le 06/12/2006 à 13:04. (lien). Évalué à 1.Oui mais...
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
Est-ce que les anglophobes pourraient aussi goûter l'humour de Linus.
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 Elie () le 30/11/2006 à 12:11. (lien). Évalué à 8.>Quelqu'un se dévoue ?
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 .
-
[^]Re: Anglais
Posté par Jean-Philippe (page perso, ) le 30/11/2006 à 12:18. (lien). Évalué à 10.Je vais essayer :
"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 (page perso, ) le 30/11/2006 à 12:22. (lien). Évalué à -4.je plussoie les deux traductions
--
Dans la vie il n'y a pas de problèmes mais que des solutions
-
[^]Re: Anglais
Posté par philippe G. (page perso, ) le 30/11/2006 à 12:36. (lien). Évalué à 2.Merci aux traducteurs.
L'est taquin Linus ;-)
-
[^]Re: Anglais
Posté par boubou (page perso, ) le 30/11/2006 à 12:47. (lien). Évalué à 10.Ou encore :
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 alveric () le 30/11/2006 à 12:55. (lien). Évalué à 6.Je n'avais pas vu avant de poster... "s'adonner", j'approuve. Par contre, "votre putain de faute", je trouve un peu fort par rapport à "your damn fault". Ou alors je me trompe sur le niveau de grossièreté de "damn"... Dans l'autre sens, je crois que "arrêter de mal vous comporter" est un peu faible par rapport à "fix your evil ways".
Mais bon, on ne va pas trop chipoter sur un tirade pareille non plus ;)
-
-
[^]Re: Anglais
Posté par alveric () le 30/11/2006 à 12:50. (lien). Évalué à 10."to rest easy" -> "rester calme", "ne pas s'énerver". Enfin, "Don't panic", quoi...
"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 :
C'est un des ces rares noyaux "parfaits". Donc, s'il n'arrive pas à compiler avec votre config (ou s'il compile, mais qu'ensuite il procède à des actes de perversion innomables sur votre teckel), vous pouvez restez calme, en sachant que c'est entièrement votre faute, et que vous devriez juste corriger vos comportements malsains.
Il y a juste le "d*mn" que je ne sais pas encore comment formuler...-
[^]Re: Anglais
-
[^]Re: Anglais
-
[^]Re: Anglais
Posté par Jean-Philippe (page perso, ) le 30/11/2006 à 16:09. (lien). Évalué à 2.Merci, j'avais effectivement un peu de mal à "franciser" ces quelques termes.
-
-
-
[^]Re: Anglais
Posté par Smarter () le 02/12/2006 à 15:20. (lien). Évalué à 6.Il y a aussi ça a la fin du mail de Linus:
You could send me and the kernel mailing list a note about it anyway, of
course. (And perhaps pictures, if your dachshund is involved. Not that
we'd be interested, of course. No. Just so that we'd know to avoid it next
time).
Que je traduirais par:
Vous pouvez de toute façon envoyer une note à propos de ce kernel à moi et à la lkml, bien sur. (Et peut-être aussi des photos, si votre teckel est impliqué. C'est pas qu'on serait intéressé, non. C'est juste pour qu'on puisse éviter ça la prochaine fois.
:)-
[^]Re: Anglais
-
libata
ce nouveau fonctionnement de libata va t il permettre de le compiler en module independamment de la config ata utilisé pour acceder au chipset de la carte mère , ça permettrait d eviter d utiliser initrd qui sous debian avec la confusion initramfs deconne un peu.
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 Thomas O () le 30/11/2006 à 15:25. (lien). Évalué à 4.Maintenant il faudrait que SMART (smartctl) supporte libata !!
Histoire qu'on puisse verifier les compteurs smart facilement et donc l'etat de nos disques.--
---
[^]Re: libata
Posté par ookaze () le 01/12/2006 à 10:22. (lien). Évalué à 3.Ce n'est peut-être pas vrai pour cette version, mais en 2.6.17, smartctl supportait sans problème un disque SATA au travers de libata.
Il y a juste une option à ajouter pour qu'il aille chercher les infos par libata.-
[^]Re: libata
Posté par Anthony Bourguignon (page perso, ) le 02/12/2006 à 08:34. (lien). Évalué à 2.Je confirme que ça marche très bien avec cette version du noyau. Il suffit de lire un peu le man et de se rendre compte qu'il faut ajouter l'option "-d ata".
--
Informaticien, mais je me soigne.
-
-
-
[^]Re: libata
Posté par Grégory SCHMITT () le 30/11/2006 à 15:36. (lien). Évalué à 5.Je te réponds directement, tu pourras poster tes résultats plus tard.
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...--
R.I.P Chris Benoit, 1967-2007-
[^]Re: libata
Posté par karmatronic () le 30/11/2006 à 16:42. (lien). Évalué à 1.oui je me rends compte que je me suis mal exprimé,le problème est pour moi de pouvoir activer en module libata mais en dur le chipset correspondant á ta carte mère.Pour moi,cela ne semble pas possible mais c est pourtant necessaire pour pouvoir identifier le graveur de dvd
comme device scsi
-
[^]Re: libata
Posté par briaeros007 () le 30/11/2006 à 19:12. (lien). Évalué à 5.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:
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.--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: libata
Posté par Anthony Bourguignon (page perso, ) le 02/12/2006 à 08:41. (lien). Évalué à 2.Ou encore plus simple, balancer lilo et passer à grub. Si on a oublié de changer le fstab, il suffit de passer la bonne option root= au noyau et ca passe (je sais, je l'ai fait). Et si le système est eclaté sur plusieurs partitions, un ajout de init=/bin/sh permet de se trouver avec un shell, on mounte ce dont on a besoin, on modifie et on redémarrage.
Mais de toute façon, c'est toujours une bonne idée de garder son ancien noyau au cas où.--
Informaticien, mais je me soigne.-
[^]Re: libata
Posté par Mjules (page perso, ) le 02/12/2006 à 13:14. (lien). Évalué à 4.ben, ça marche aussi avec lilo ça vu que ce sont des options passées au noyau.
-
[^]Re: libata
Posté par djibb (Jabber id, page perso, ) le 03/12/2006 à 07:43. (lien). Évalué à 5.oui.... mais bon... avec grub tu as l'autocomplétion de tout... c'est à dire que tu as eu un renommage de ton disque... et tu as oublié de refaire un "lilo" aprés... et bien avec grub, tu édites la ligne au démarrage (e) puis tu fais des tabulations, comme en shell. et ca te donne les partitions, leur type, puis tu rentres dans les arborescences (je suis en ext3 donc ca passe impec) et tu vas chercher ton noyau puis l'initrd... une fois booté y'a plus qu'a mettre en dur.
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.--
http://astrolix.org
-
-
-
-
[^]Re: libata
Posté par José JORGE (Jabber id, page perso, ) le 30/11/2006 à 21:11. (lien). Évalué à 3.> Comment faire pour ralentier mes deux >dvdroms pour leur éviter de tourner à toute berzingue, et donc répliquer >hdparm -E ? Mystère... je cherche.
essaye 'eject -x' ça fait la même chose, et au chargement du CD svp ;-)
-
[^]Re: libata
Posté par karmatronic () le 09/12/2006 à 22:00. (lien). Évalué à 1.eh bien je me reponds moi même,finalement , le 2.6.19 me donne quelques petits problèmes au niveau des compils (á ma grande surprise),mais bon j ai insisté avec le 2.6.18 que j avais sous la main , et voili voilou j ai enfin le dma actif sur mon graveur dvd !
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 Diplodocus (Jabber id, page perso, ) le 11/12/2006 à 15:31. (lien). Évalué à 3.Libata ?? Cela veux-il dire la fin du nommage hd* pour les disques dures (sachant que hd =hard drive).
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
# L'algorithme de gestion de la congestion des réseaux TCP[...]
# Une infrastructure permettant de "marquer" les paquets réseau [...]
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 PasChauve PasOunet () le 30/11/2006 à 14:20. (lien). Évalué à -1.Rassure moi , ta question est vraiment serieuse ?
-
[^]Re: Une vraie question
Posté par neologix (page perso, ) le 30/11/2006 à 14:37. (lien). Évalué à 4.En fait je pense qu'il fait allusion au fait que Linux est un noyau monolithique, et que les microkernels sont l'avenir...
Dommage que le Hurd soit mort, enfin y'a apparemment Minix qui vit sa vie.-
[^]Re: Une vraie question
Posté par briaeros007 () le 30/11/2006 à 19:14. (lien). Évalué à 2.les exokernels sont sympa aussi...
--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Une vraie question
Posté par Jul (page perso, ) le 17/12/2006 à 22:42. (lien). Évalué à 2.et les endokernels ? sont sympa aussi.
-
[^]Re: Une vraie question
-
-
-
-
-
[^]Re: Une vraie question
Posté par Pierre Tramonson () le 30/11/2006 à 14:22. (lien). Évalué à 10.Oui la question mérite d'être posée. Pour moi, on ne devrait y mettre que des choses vraiment utiles, genre J2EE.
-
[^]Re: Une vraie question
Posté par Pascal (page perso, ) le 30/11/2006 à 14:39. (lien). Évalué à 10.Ce n'est pas une uestion si idiote que cela...
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 () le 30/11/2006 à 16:20. (lien). Évalué à 3.> Qu'est-ce qui techniquement empeche d'implementer les protocoles TCP, IP, voire de couche 2 dans une librairie tournant en user-space??? Rien.
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 () le 30/11/2006 à 18:25. (lien). Évalué à 6.Au contraire il y a moins de changement de contexte si tu fais du end-to-end vers l'espace utilisateur. (voire les articles http://lwn.net/Articles/169961/ et ceux sur kevent le successeur des net channels)
-
[^]Re: Une vraie question
Posté par reno () le 01/12/2006 à 09:23. (lien). Évalué à 1.Je connais l'article sur channel de 'Van Jacobson', mais bien que les performances montrée dans l'article sont impressionnantes, il me semble que certaines portions du firewall posent problèmes dans cette architecture (le NAT par exemple ne me semble pas évident).
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 (page perso, ) le 01/12/2006 à 18:11. (lien). Évalué à 1.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.
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 () le 02/12/2006 à 18:31. (lien). Évalué à 1.Pas d'accord: si c'est géré par le kernel, la connection TCP s'établira sans problème, même avec le processus destination swappé.
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 () le 27/12/2006 à 13:48. (lien). Évalué à 2.Juste un peu ? mwarf
T'as jamais fait trasher une box comme un malade toi :)-
[^]Re: Une vraie question
-
-
-
-
-
-
-
[^]Re: Une vraie question
Posté par CoinKoin () le 30/11/2006 à 16:51. (lien). Évalué à 2.Le noyau est autrement plus facile à multithreader que les applications de l'espace utilisateur. Ne serait-ce que parce qu'il y a une pile noyau par flot d'exécution en espace utilisateur.
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 Benjamin G. ( Prae ) (page perso, ) le 30/11/2006 à 21:27. (lien). Évalué à 2.Je dois avouer que j'ai acquiescé un léger sourire quand j'ai vu ton commentaire, mais après coup je me suis dit que ca pouvait être utile pour les virtual-hosting.
Speedstep Centrino
Hello
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
libata et les noms de devices
Si j'ai bien compris, si on utilise libata pour gérer ses disques ide, leur nom n'est plus /dev/hdX mais devient /dev/sdX. Si vous utilisez ça, pensez à mettre à jour votre fstab (si vous n'utilisez ni les labels ni les uuids)
Modèle de développement
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.
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 (page perso, ) le 30/11/2006 à 19:11. (lien). Évalué à 3.y'a pas un kernel dev qui maintient un noyau stable basé sur le 2.6.16 ?
-
[^]Re: Modèle de développement
Posté par taratatatata () le 30/11/2006 à 22:58. (lien). Évalué à 9.Ils avaient dit que le 2.6.16 serait un kernel stable et maintenu le plus longtemps possible. Les distro stables sur le long terme étaient censées l'utiliser.
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
-
[^]Re: Modèle de développement
Posté par djibb (Jabber id, page perso, ) le 30/11/2006 à 19:23. (lien). Évalué à 8.TOI !! tu as une ubuntu !
--
http://astrolix.org
-
[^]Re: Modèle de développement
Posté par José JORGE (Jabber id, page perso, ) le 30/11/2006 à 21:15. (lien). Évalué à 2.Ceux qui veulent bosser prennent une distribution mûre, cad vieile de 6 mois minimum ;-)
-
[^]Re: Modèle de développement
Posté par Pierre Jarillon (page perso, ) le 06/12/2006 à 11:49. (lien). Évalué à 1.Six mois, c'est peut être pas indispensable. Mandriva 2007 a un gros paquets d'updates qui au bout de deux mois lui assure un fonctionnement très fiable.
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 () le 01/12/2006 à 09:07. (lien). Évalué à 10.C'est un des ces rares noyaux "parfaits". Donc, s'il n'arrive pas à compiler avec ta config (ou s'il compile, mais qu'ensuite il procède à des actes de perversion innomables sur votre teckel), tu peux rester calme, c'est entièrement de ta faute. Tu devrais juste corriger tes comportements malsains.
-
[^]Re: Modèle de développement
Posté par iug () le 01/12/2006 à 11:08. (lien). Évalué à 2.
-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
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 (page perso, ) le 02/12/2006 à 01:13. (lien). Évalué à 2.Chipset ATI.
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 () le 02/12/2006 à 12:11. (lien). Évalué à 3.Il s'agit de régressions, et apparemment tout le monde s'en fout.
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 (Jabber id, page perso, ) le 06/12/2006 à 00:14. (lien). Évalué à 3.C'est pas forcément une régression. Des fois, un changement au niveau d'un composant, peut changer / ajouter des fonctionnalités et/ou des options. A l'upgrade, on n'est pas au courant, et on casse tout. Un module ou une fonction peut changer le comportement d'une autre, c'est tellement complexe que bon...
Ca m'est arrivé avec les changements sur l'IOMMU dans le 2.6.18.
-
-
FAT et "-o flush"
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.
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 Nicolas Parein (page perso, ) le 30/11/2006 à 20:08. (lien). Évalué à 3.Faut-il faire une mise à jour de "mount" pour en profiter ? (je pense que oui perso)
-
[^]Re: FAT et "-o flush"
Posté par Pascal Terjan (Jabber id, page perso, ) le 01/12/2006 à 00:20. (lien). Évalué à 6.Je ne pense pas, mount transmet les options même s'il ne les connait pas.
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
Je ne sais pas vous, mais moi je suis sidéré de voir qu'il y'a même pas un an, certains (pas ici je vous rassure) criaient au scandale suite aux propos d'Andrew Morton concernant de trop nombreux bugs du noyau non corrigé (la majorité ayant été corrigés peu de temps après), et qu'aujourd'hui une version du noyau sort et est qualifiée par Linus lui même de "rare perfect kernel". Je suis sidéré et admiratif devant la réactivité des développeurs, chapeau !
-
[^]Re: Evolution fulgurante
-
[^]Re: Evolution fulgurante
Posté par lejocelyn () le 30/11/2006 à 23:09. (lien). Évalué à 1.Vous croyez qu'il faut lui dire qu'il reste des bugs ? (pas à Linus Torvald hein ...)
-
[^]Re: Evolution fulgurante
Posté par Franck Charpentier () le 01/12/2006 à 06:14. (lien). Évalué à 0.pfff, si on ne peut même plus s'entousiasmer :o
-
[^]Re: Evolution fulgurante
-
-
Bootsplash
Pour ceux comme moi qui aiment a utiliser bootsplash, le bootsplash-3.1.6-2.6.18.diff, dernier disponible sur ftp://ftp.openbios.org/pub/bootsplash/kernel/ ne compile pas.
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
-
[^]Re: Bootsplash
Posté par Brice Goglin () le 01/12/2006 à 09:25. (lien). Évalué à 2.C'est un peu caca cette détection :) Il y a des distribs qui ont backporté les modifs liées à autoconf.h, config.h et utsrelease.h dans des noyaux < 2.6.18 (notamment des fedora 2.6.17 si je me souviens bien). Donc ces tests basés sur les versions ne marcheront pas toujours.
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 () le 01/12/2006 à 10:27. (lien). Évalué à 0.Je n'essaierai pas de défendre ma solution puisque je l'ai faite a l'arrache hier soir pour que ça fonctionne, et que je suis très loin d'être un spécialiste du noyau.
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 (page perso, ) le 02/12/2006 à 15:54. (lien). Évalué à 1.Sinon il y a splashy qui est entièrement en mode user.....
http://alioth.debian.org/projects/splashy/
UML ?
Juste pour info parce qu'on n'en parle pas du tout, il existe aussi user linux mode (ULM) qui est intégré au noyau,
http://user-mode-linux.sourceforge.net/index.html
Donc on a déjà Xen, GFS2, user-mode-linux :-)
Reiser4
Cool pour l'ext4 mais visiblement, toujours pas de reiser4 en vu :/
Me trompe-je ?
-
[^]Re: Reiser4
Posté par Nicolas Cornu () le 08/12/2006 à 14:48. (lien). Évalué à 2.Pour info, le principal développeur de reiserfs a été arrêté pour le meurte de sa femme aux Etats-Unis. Cela va sûrement ralentir son développement à moins qu'on lui file un PC sous Nux et une connex adsl en prison...mais j'en doutes -_-'
-
[^]Re: Reiser4
Posté par Boa Treize (page perso, ) le 09/12/2006 à 12:45. (lien). Évalué à 4.Arrêté parce qu'on le suspecte d'avoir tué sa femme, dont on n'a retrouvé aucune trace.
-
[^]Re: Reiser4
Posté par Pascal (page perso, ) le 09/12/2006 à 12:57. (
-
-
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.