Rappelons le processus ayant conduit à la sortie de cette nouvelle version. Après la sortie du 2.6.19, Andrew Morton a indiqué la liste des patchs suffisamment stables pouvant migrer de sa branche de test (la -mm) vers la branche de Linus pendant la période d'intégration. Cette période, d'une durée de deux semaines, permet l'ajout de toutes les nouveautés prévues.
Une fois ce délai de deux semaines écoulé, Linus annonce la sortie de la première release-candidate (la -RC1) et il n'est plus permis d'ajouter de nouvelles fonctions. Seul le travail de correction des bugs et de stabilisation est autorisé, rythmé régulièrement par les releases-candidates successives toutes les quelques semaines. La -RC3 est ainsi apparue juste avant la nuit du réveillon pour éviter, selon Linus, tout problème avec l'organisation MADR ("Mothers Against Drunk Releases").
La RC6, annoncée le 24 janvier dernier (voir le message d'annonce) devait être la version finale, cependant quelques régressions persistaient et Linus a insisté le 30 janvier pour sortir une RC7 afin de corriger cela.
En dépit des espoirs initiaux d'une version facile à développer, car sans grandes nouveautés conceptuelles, le chemin n'a pas été semé de roses. Un bug vicieux et subtil a notamment déclenché une véritable traque à grande échelle dont la saga est narrée en plusieurs épisodes sur le site Kerneltrap.
C'est Linus lui-même qui a finalement eu la peau du bug et un article explicatif (très technique) est disponible ici pour les curieux. Les nouveautés marquantes du nouveau noyau :
- La principale innovation de la version 2.6.20 est l'intégration de la technologie de virtualisation KVM dans le noyau. C'est la première fois qu'une telle technologie est acceptée dans la branche principale (mainline) car ses concurrents (Xen et autres) sont des patchs externes. C'est la simplicité qui a payé car KVM consiste seulement en un module noyau et un composant en espace utilisateur. Il s'appuie sur les extensions hardware des processeurs récents (Intel VT et AMD SVM). Selon cet article détaillé la solution KVM est plus simple et plus maintenable et la communauté des développeurs va maintenant converger vers cette solution au détriment de Xen.
- Une option de fonctionnement du noyau à 300 Hz a été ajoutée. Elle permet d'obtenir des nombres entiers quand on la divise par le nombre d'images par seconde des vidéos PAL ou NTSC. Les formats à 25 images/s et 30 images/s sont donc plus facilement supportés.
- Le support du protocole UDP-Lite est ajouté dans le noyau. UDP-Lite est spécialement adapté pour le transport en streaming des flux média. Un survol technique de ce nouveau protocole est disponible sur ce wiki
- Toujours en ce qui concerne le réseau on note que DCCP supporte maintenant l'infrastructure de sécurité SELinux ce qui permet un contrôle plus fin.
- Les bus SCSI peuvent maintenant être scannés de façon asynchrone ce qui améliore la vitesse de démarrage.
- Le système permettant d'observer les entrées/sorties (I/O Accounting) est largement modifié pour améliorer sa précision. Les développeurs Samba se réjouissent de cette amélioration qui va permettre d'observer plus précisément le comportement de leur logiciel dans tous les cas de figure.
- Le système de fichier pour cluster GFS2 (introduit dans le noyau précédent) est largement amélioré. Le gestionnaire des verrous (lock manager) supporte maintenant les connections TCP.
- La couche générique HID n'est plus réservée seulement aux pilotes des périphériques USB et accepte maintenant d'autres protocoles (Bluetooth...etc). L'utilisation de cette couche générique permet une réutilisation et un partage optimal du code.
- Le mécanisme de Workqueue est largement modifié afin de réduire drastiquement son empreinte mémoire. Cela a conduit à des modifications de l'API et à des corrections à travers tout le noyau. Workqueue est utilisé pour gérer les processus afin de les "endormir" et les "réveiller" après un intervalle de temps spécifié.
- Le travail d'annotation du code du noyau continue afin de permettre les travail de sparse. Cet outil, écrit à l'origine par Linus Torvalds, utilise des annotations sémantiques présentes dans le code pour faire une analyse des erreurs potentielles lors de la compilation (pointeurs mémoires, verrous...etc). Le sous-système réseau est maintenant largement annoté pour permettre cette analyse automatique.
- Pour améliorer encore la qualité et la robustesse du noyau une infrastructure d'injection d'erreur a été ajoutée. Cela semble paradoxal mais c'est en fait très simple : le noyau Linux actuel est très stable ce qui entraîne que le code de gestion des erreurs n'est pas souvent sollicité. Pour s'assurer de la robustesse de ce code la nouvelle infrastructure va permettre de générer des erreurs afin de vérifier que le noyau se comporte comme prévu dans tous les cas imaginables. Une documentation complète est disponible pour utiliser au mieux ce mécanisme original.
- Un nettoyage des fichiers de header de Linux a été effectué. Cela diminue le nombre d'includes afin d'accélérer la compilation du noyau.
- Comme d'habitude énormément de pilotes sont améliorés, corrigés ou ajoutés. Il est impossible de tous les citer mais, à titre d'exemple parmi d'autres, on peut noter l'intégration du pilote "usbvision" qui permet le support générique de plus de cinquante webcams USB.
En ce qui concerne les évolutions futures du noyau Linux on peut se pencher sur les patchs qui ont rejoint la branche expérimentale -mm d'Andrew Morton.
Une première évolution sera la possibilité d'avoir des entrées/sorties asynchrones dans les fichiers tampons (Asynchronous buffered file I/O). Actuellement ces entrées/sorties asynchrones existent seulement en cas de connexion directe mais si le système de fichier utilise la couche d'abstraction (Virtual File System) alors cette possibilité n'existe plus. Une série de patchs est maintenant en phase de test afin de corriger cela.
On trouve également dans la branche -mm le support unifié des pilotes en espace utilisateur. Il peut être utile dans certains cas, par exemple quand il est trop gros pour rejoindre le noyau, de faire fonctionner un pilote en tant que programme en espace utilisateur (userspace). Afin d'éviter l'anarchie de douzaines d'implémentations différentes il sera possible d'utiliser cette future interface standard. Le support unifié permettra de n'implanter dans l'espace du noyau qu'un minuscule module qui communiquera avec le pilote complet vivant, lui, en espace utilisateur.
Aller plus loin
- Les nouveautés de la version 2.6.20 (10 clics)
- Résumé de l'intégration des patchs partie 1 (2 clics)
- Résumé de l'intégration des patchs partie 2 (2 clics)
# Le linux nouveau est arrivé!
Posté par windu.2b . Évalué à 4.
Mais j'aurais voulu avoir quelques informations supplémentaires: par exemple, existe-t-il un site répertoriant les webcams USB gérées par le noyau?
De même, pourquoi la fréquence de 300Hz a-t-elle été choisie pour donner des nombres entiers en PAL et NTSC? Je suppose qu'il fallait un nombre divisible à la fois par 25 et par 30, mais dans ce cas-là, pourquoi ne pas avoir choisi 150?
Si quelqu'un peut éclairer ma lanterne, je l'en saurais gré
[^] # Re: Le linux nouveau est arrivé!
Posté par Olivier Serve (site web personnel) . Évalué à 10.
25Hz et 30Hz correspondent à une moitié d'une image entrelacée. Pour l'image complète, il faut donc compter avec 50 et 60Hz. D'où les 300Hz.
[^] # Re: Le linux nouveau est arrivé!
Posté par Pierre Tramo (site web personnel) . Évalué à 5.
[^] # Re: Le linux nouveau est arrivé!
Posté par oliv . Évalué à -2.
[^] # Re: Le linux nouveau est arrivé!
Posté par Zenitram (site web personnel) . Évalué à 5.
La télévision d'après-demain, si tu pensais à ça, c'est 2000 (environ, pas encore décidé)*4096 ("4K" pour son petit nom) en 30 images/seconde.
La télévision d'après-après-demain, c'est du "4K" en 60 images/seconde.
Bref, le 120, 180 Hz, c'est du Marketing foireux qui n'existe pas en réalité dans notre monde numérique (il vient des marketeux qui quand ils recoivent un signal analogique en entrelacé, augmente les images pour compenser cet entrelacement. Avec le numérique 100%, on arrête de plus en plus l'entrelacé pour passer à du progressif, mais aujourd'hui sans augmenter le nombre d'image/seconde)
[^] # Re: Le linux nouveau est arrivé!
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: Le linux nouveau est arrivé!
Posté par Prosper . Évalué à 2.
Pour la télé "de demain" c est 1080p@60 , pour le cinéma ( blueray et hd-dvd ) c est 1080p@24
Bref, le 120, 180 Hz, c'est du Marketing foireux
Absolument pas , 120hz c est la fréquence idéale pour afficher a la fois du 24fps et du 60fps ( ce sont juste des multiples de 120 ) sans avoir de phénomene de judder .
[^] # Re: Le linux nouveau est arrivé!
Posté par Zenitram (site web personnel) . Évalué à 4.
Ah? C'est nouveau, je ne vois rien comme ca...
La TNT sait a peine afficher du 720p@30 (ou du 720i@60, mais ce sont 60 demi-images!), et aucun contenu n'est enregistré en 1080p@60, donc "demain", c'est un peu présomptueux non?
C'est des choses plus nécessaires avec le numérique, l'écran n'a plus de balayage, donc il peut s'adapter a chaque 'fréquence' sans faire de scintillement ou autre.
C'est beau le numérique ;-)
[^] # Re: Le linux nouveau est arrivé!
Posté par Nicolas Boulay (site web personnel) . Évalué à 7.
C'est beau le numérique ;-)
hum... je crois que tu es passé à coté du problème.
Numérique ou pas. Un film enregistré à 24fps, à une image prévu pour rester 1/24s à l'écran. Si ton écran diffuse à 60 fps c'est impossible. Chaque image peut être mis sur 2 ou 3 frame mais cela fera du 1/30s ou du 1/20s mais jamais 1/24s.
"La première sécurité est la liberté"
[^] # Re: Le linux nouveau est arrivé!
Posté par Christophe Merlet (site web personnel) . Évalué à 0.
[^] # Re: Le linux nouveau est arrivé!
Posté par Miod in the middle . Évalué à 4.
[^] # Re: Le linux nouveau est arrivé!
Posté par Pol' uX (site web personnel) . Évalué à 1.
Adhérer à l'April, ça vous tente ?
[^] # Re: Le linux nouveau est arrivé!
Posté par Antoine . Évalué à 6.
Je signale que c'est l'inverse.
[^] # Re: Le linux nouveau est arrivé!
Posté par Nikoo . Évalué à 2.
http://usbvision.sourceforge.net/index.php?page=device
qui parle de cartes TV, et de vieux noyaux linux (2.6.1)......
Quelqu'un a trouvé mieux ? :-/
[^] # Re: Le linux nouveau est arrivé!
Posté par dark_moule . Évalué à 3.
Il y a une catégorie pour les périphériques vidéo (webcam, etc) : http://www.qbik.ch/usb/devices/showdevcat.php?id=9
J'espère que tu vas y trouver ton bonheur.
[^] # Re: Le linux nouveau est arrivé!
Posté par Nikoo . Évalué à 1.
C'est juste que la news indique :
"pilote usbvision maintenant intégré super feature car il permet le support de près de 50 modèles de webcam. "
Or, usbvision sert à supporter des cartes TV, donc je comprends pas trop...
Si ce pilote permet le support de 50 webcams, ben je les ai pas trouvé.
Et je pense que ça intéresse pas mal de monde, si c'est réellement le cas.
Merci d'autres retours.
[^] # Re: Le linux nouveau est arrivé!
Posté par patrick_g (site web personnel) . Évalué à 4.
The "usbvision" driver has been merged, adding support for "more than 50" USB video camera devices.
[^] # Re: Le linux nouveau est arrivé!
Posté par Nikoo . Évalué à 2.
J'essaie juste de mettre en exergue que sur le site d'usbvision que j'ai mis plus haut (à moins que ce ne soit pas le bon site) ben ya rien de frais, et que ça parle de cartes TV.
C'est pour ça que je trouve ça bizarre.
Si le support de webcam d'une certaine marque est intégré dans le noyau alors je m'empresserai de faire de la pub pour elle, mais j'attends d'avoir cette marque ;-).
P.S. bon, ok, certains vont me dire, takachercher... :D
[^] # Re: Le linux nouveau est arrivé!
Posté par Guillaume . Évalué à 1.
commit 781aa1d1ab7ba13314af0af6c5d70c0eb0e96bf4
....
V4L/DVB (4922): Add usbvision driver
This patch adds usbvision into V4L/DVB HG tree.
Usbvision driver is a GPL driver, made by:
Joerg Heckenbach <joerg@heckenbach-aw.de>
and
...
A partir des adresses mèl données j'ai cherché un peu sur internet et il s'agit bien du projet sourceforge que tu cites.
Il semblerait donc qu'il s'agisse d'un pilote pour cartes d'acquisition vidéo usb (Hauppauge, Pinnacle, Miro, ...).
CQFD! (^^)
[^] # Re: Le linux nouveau est arrivé!
Posté par Jéjé de Grenoble . Évalué à 2.
à base de N1003/1004/1005... je ne sais pas ce que c'est...
mais vu la dépendance sur SAA711A, c'est surement des cartes TV
+config VIDEO_USBVISION
+ tristate "USB video devices based on NT1003/1004/1005"
+ depends on I2C && VIDEO_V4L2
+ select VIDEO_SAA711X if VIDEO_HELPER_CHIPS_AUTO
+ ---help---
+ There are more than 50 different USB video devices based on
+ NT1003/1004/1005 USB Bridges. This driver enables using those
+ devices.
+
[^] # Re: Le linux nouveau est arrivé!
Posté par Nikoo . Évalué à 1.
[^] # Re: Le linux nouveau est arrivé!
Posté par Mathias Bavay (site web personnel) . Évalué à 0.
Mathias
[^] # Re: Le linux nouveau est arrivé!
Posté par cactus2000 . Évalué à 3.
Je suis à l'origine de ce changement, car c'est un ami qui a tout repris pour faire fonctionner mon tuner usb (win TV usb).
Vous pouvez en consulter les multiples modif en recherchant son nom (thierry merle).
A noter aussi qu'il continue à optimiser les drivers... ;)
[^] # Re: Le linux nouveau est arrivé!
Posté par patrick_g (site web personnel) . Évalué à 4.
C'est uniquement des tuners TV et pas du tout des webcams USB ?
[^] # Re: Le linux nouveau est arrivé!
Posté par cactus2000 . Évalué à 3.
Mais bon, comme je n'y comprends pas grand chose, je ne sais pas s'il y a autre chose, ou une fonction dérivée pour les webcams.
[^] # Re: Le linux nouveau est arrivé!
Posté par patrick_g (site web personnel) . Évalué à 4.
[^] # Re: Le linux nouveau est arrivé!
Posté par gvallee . Évalué à 1.
Apres je ne sais pas si les tuners TV sont inclus dans ce groupe...
Mes 2 cents...
# Rahhhhhh
Posté par Christophe Merlet (site web personnel) . Évalué à 5.
2 grosses nouveautés high tech :
La paravirtualisation avec l'intégration de KVM pour exploiter la virtualisation matériel des puces Intel et AMD.
Le relogement du kernel, idéal pour kdump sans avoir besoin d'un second kernel compilé sur mesure. Curieusement, le patch permetant le relogement du kernel est tout petit !!
[^] # Re: Rahhhhhh
Posté par patrick_g (site web personnel) . Évalué à 6.
En fait il indique explicitement ici => http://lkml.org/lkml/2007/2/4/119 qu'il a essayé de faire une release la plus stable possible :
I tried rather hard to make 2.6.20 largely a "stabilization release".
Unlike a lot of kernels lately, there aren't really any big fundamental changes to some core infrastructure area, and while we always have bugs, I really am hoping that we fixed many more than we introduced.
Rappelons que ce kernel sera celui de la future Ubuntu Feisty et, je crois, de la future Fedora 7. C'est donc un noyau important et je trouve très bien que l'accent soit mis avant tout sur la plus grande stabilité possible.
[^] # Re: Rahhhhhh
Posté par Christophe Merlet (site web personnel) . Évalué à 5.
Ce n'est pas tout à fait ça qu'il dit.
Il dit précisement :
"Unlike a lot of kernels lately, there aren't really any big fundamental
changes to some core infrastructure area,"
En français, les fondamentaux du système n'ont pas été bouleversé. Ce qui est différent de "ne pas avoir ajouté de nouveautés".
Or, la paravirtualisation et le relogement du système ne touche justement pas au fondamentaux du noyau, ce sont juste des fonctionnalités supplémentaires. Ce qui ne contredit en rien linus Torvalds.
Et comme je le disais, je suis justement surpris de la petite taille des patchs pour ajouter ses fonctionnalités.
# debian
Posté par Rémi baudruche . Évalué à 1.
Bon sans plaisanterie, je sait pas comment dire ça pour pas me faire mal voir
mais je comprend pas pourquoi le 2.6.19 est jamais rentré dans les dépots
Rémi
[^] # Re: debian
Posté par MrTout (site web personnel) . Évalué à 2.
[^] # Re: debian
Posté par Rémi baudruche . Évalué à 1.
j'essaye ça :
"deb http://kernel-archive.buildserver.net/debian-kernel/dists/ sid"
mais ça marche pas.
[^] # Re: debian
Posté par arthurr (site web personnel) . Évalué à 1.
deb http://kernel-archive.buildserver.net/debian-kernel/ sid main
[^] # Re: debian
Posté par arthurr (site web personnel) . Évalué à 2.
deb http://kernel-archive.buildserver.net/debian-kernel/ trunk main
[^] # Re: debian
Posté par MrTout (site web personnel) . Évalué à 1.
Mais attention, paquets pas officiels, moins testés, etc.
# 2.6.20 et Core2Duo et JMicron
Posté par DebianOhOui . Évalué à 1.
Chez moi les RC4, 5 et 6 m'empêchaient d'utiliser un de mes disques durs, mon lecteur de cartes mémoires,...et internet!
Carte-mère Asus P5B-VM.
J'attends l'arrivée du 2.6.20 final chez debian pour voir s'il y a eu un miracle:
http://kernel-archive.buildserver.net/debian-kernel/pool/mai(...)
[^] # Re: 2.6.20 et Core2Duo et JMicron
Posté par Pat _ . Évalué à 1.
Il y a eu pas mal de changement d'organisation dans la config de netfilter et du coup certains paramètres n'étaient pas retrouvés après un simple make oldconfig... j'ai du les reconfigurer à la main pour que tout le nécessaire soit compilé (en particulier le NAT) et retrouver l'accès au Net.
[^] # Re: 2.6.20 et Core2Duo et JMicron
Posté par DebianOhOui . Évalué à 1.
Est-ce que tu aurais le temps de copier tes modifications ici pour tous les linuxiens qui vont avoir la même mauvaise surprise?
Sinon, tant pis, c'est déjà une bonne piste pour google.
[^] # Re: 2.6.20 et Core2Duo et JMicron
Posté par DebianOhOui . Évalué à 1.
[^] # Re: 2.6.20 et Core2Duo et JMicron
Posté par Pat _ . Évalué à 1.
Une rapide explication de ce qui est nécessaire pour qu'il fonctionne est donnée ici :
http://www.fs-security.com/docs/kernel.php
Si tu as installé le 2.6.20 sans trop te poser de question (make oldconfig et basta, comme je l'ai d'abord fait), certaines parties de netfilter ne sont pas compilées. Il faut faire un make menuconfig (ou gconfig ou....), retrouver les options indiquées dans la page ci dessus, les activer et recompiler.
Je ne peux pas etre plus précis ici, je n'ai pas les infos sous la main... c'est une bonne occasion de te plonger un peu la dedans.
Bon courage !
[^] # Re: 2.6.20 et Core2Duo et JMicron
Posté par DebianOhOui . Évalué à 2.
En fait je me contente de télécharger les .deb du kernel, de cliquer dessus, et Kpackage les installe!
Je me demande ce qui va se passer pour des millions de nouveaux utilisateurs de linux avec les modifications à ce niveau, et au niveau de l'unification des drivers pour les disques durs. Ça risque d'être le chaos. Je ne vois vraiment pas comment l'utilisateur normal de Windows pourrait s'en sortir.
[^] # Re: 2.6.20 et Core2Duo et JMicron
Posté par Pat _ . Évalué à 2.
mais pour ceux qui veulent du "bleeding edge", c'est sur qu'il faut parfois retrousser les manches :)
[^] # Re: 2.6.20 et Core2Duo et JMicron
Posté par DebianOhOui . Évalué à 1.
P.S.: il y en a qui ont le doigt sur la gachette ici!
[^] # Re: 2.6.20 et Core2Duo et JMicron
Posté par DebianOhOui . Évalué à 1.
Par contre j'ai toujours le même disque dur qui ne marche pas alors qu'il marche parfaitement sous 2.6.19. C'est un PATA sur port SATA par un adaptateur (comme un autre des mes disques durs). Au boot il me dit qu'il faut que je fasse un fschck sur ce disque dur /dev/sdc1. Résultat, quand je met une carte SD dans le lecteur mémoire, celui-ci essaie de prendre /dev/sdc1 au lieu de /dev/sdd1 normalement et ne marche pas non plus.
J'ai aussi ce message qui fait peur dans mes logs: Feb 5 09:08:19 localhost kernel: TCP: Treason uncloaked! Peer 86.142.4.254:53202/47101 shrinks window 1039080972:1039083892. Repaired.
Et plus généralement des tonnes de messages de connections INBOUND.
[^] # Re: 2.6.20 et Core2Duo et JMicron
Posté par DebianOhOui . Évalué à 1.
Et finalement internet ne marche pas quand Firestarter est activé il me semble. Pourtant mon kernel est un kernel debian officiel. C'est vraiment chiant. Pour moi l'objectif de Linux est raté: ce kernel n'est pas le moins buggé depuis longtemps, au contraire.
[^] # Re: 2.6.20 et Core2Duo et JMicron
Posté par abramov_MS . Évalué à 2.
Sinon je vois pas trop comment Linus (pas Linux) pouvait deviner qu'il y avait une regression. Certes d'autre personnes doivent avoir le meme probleme mais si ils pensent que qq'un d'autre l'a signale ca va pas faire avancer les choses...
[^] # Re: 2.6.20 et Core2Duo et JMicron
Posté par DebianOhOui . Évalué à 1.
En plus je ne sais pas où on fait les bug reports pour le kernel, et je ne sens pas qualifié pour aller déranger les génies de linux. Mais je vais devoir chercher.
[^] # Re: 2.6.20 et Core2Duo et JMicron
Posté par Pascal . Évalué à 4.
Tu crées uncompte et tu rapporte le bug.
Et puis,n'aie pas peur les "génies du kernel" aiment etre dérangés pour des rapports de bug. C'est très important que les bugs soient rapportés dans un processus de dévellopement libre...
Le seul truc, qu'il faut savoir, c'est qu'il te faut expliquer le plus clairement possible, et avec le maximum de détails ton bug, ton environnement, dans quel cas il apparait et comment le reproduire. Et si possible: appuyés par des extraits de logs .
[^] # Re: 2.6.20 et Core2Duo et JMicron
Posté par rdem . Évalué à 2.
Pour firestarter, coir le commentaire netfilter dessous, il faut refaire la selection des paquets netfilter.
(J'ai eu le problème SATA ET NetFilter, mais ce n'est pas la mer a boire.)
[^] # Re: 2.6.20 et Core2Duo et JMicron
Posté par DebianOhOui . Évalué à 1.
[^] # Re: 2.6.20 et Core2Duo et JMicron
Posté par rdem . Évalué à 1.
Mais je ne suis pas non plus une référence, et loin de la.
# Patch temps-réel
Posté par iug . Évalué à 4.
Une partie des nouveautés apportés par le patch a déjà été mergée dans la version 2.6.19 : diminution du nombre de réveils du noyau en l'absence de tâches à scheduler (utile pour l'économie d'enrgie), timer haute résolution.
Ingo a changé son modèle de développement et suis maintenant la branche principale du noyau : il intègre les modifications apportées dans les versions 2.6.x.y au fur et à mesure. Auparavant, ses patches n'étaient fournies que pour les versions en '.x'.
Ca sera peut-être un peu juste pour l'inclusion dans le 2.6.21, mais on devrait voir ça en 2.6.22.
A titre d'exmple, le serveur audio Jack fonctionne sans problème avec 1 ms de latence à l'aide ce patch, là où le noyau standard a déjà du mal avec 50 ms de latence.
http://people.redhat.com/mingo/realtime-preempt/
[^] # Re: Patch temps-réel
Posté par Jean-Denis Vauguet (site web personnel) . Évalué à 1.
Le soucis actuel est qu'il faut souvent recompiler son kernel, ce qui n'est pas forcément aisé pour un musicien, ou parfois tout bêtement impossible (par exemple, le patch d'Ingo ne passe pas sur la version usuelle du kernel d'Ubuntu Edgy). Mais de plus en plus de distributions fournissent des paquets « lowlatency » ou « realtime » où tout est déjà prêt.
Avec l'intégration du patch dans la branche principale, ça deviendra encore plus simple ; de quoi motiver les gens à s'intéresser ''enfin'' à linux pour la MAO ?
[^] # Re: Patch temps-réel
Posté par zerbro . Évalué à 10.
Quand on vous dit que linuxfr est un repère de communistes !
[^] # Re: Patch temps-réel
Posté par iug . Évalué à 1.
# Hans si tu nous lis !
Posté par kolter (site web personnel, Mastodon) . Évalué à -9.
"Hans, boooohh, Reiserfs 4 ça devait vraiment être de la m**** car il et toujours pas intégré dans Linux ..."
M.
[^] # Re: Hans si tu nous lis !
Posté par patrick_g (site web personnel) . Évalué à 5.
Ou alors c'est moi qui suis en panne d'humour noir aujourd'hui.
[^] # Re: Hans si tu nous lis !
Posté par Charles-Victor DUCOLLET . Évalué à -1.
[^] # Re: Hans si tu nous lis !
Posté par Nikoo . Évalué à 0.
Moi, j'ai trouvé ça drôle.
# ext4
Posté par Frederic Bourgeois (site web personnel) . Évalué à 3.
Il était dans le noyau 2.6.19rc1-mm1, est-il bientôt opérationnel ?
[^] # Re: ext4
Posté par patrick_g (site web personnel) . Évalué à 2.
ici on trouve quelques mentions de délai => http://lwn.net/Articles/189950/
Je parie pour la fin 2007.
[^] # Re: ext4
Posté par reno . Évalué à 2.
Un FS n'est pas déstabilisant pour le reste (si tu n'as pas de partition ext4) donc les devs ont acceptes qu'ext4 soit directement dans le kernel même en cours de développement.
[^] # Re: ext4
Posté par IsNotGood . Évalué à 3.
La raison principale selon moi, est qu'il y a une communauté de développeur nombreuse (toute chose étant égale par ailleurs), douée et avec une solide réputation de sérieux.
L'autre raison est que ext4 n'est pas une écriture complete d'un FS, mais une évolution (majeur) d'un FS existant.
Ext4 a aussi un roadmap assez précis.
# netfilter
Posté par neologix . Évalué à 1.
Ca fait 3 fois que je recompile mon noyau en essayant différentes options, mais rien n'y fait...
Merci
[^] # Re: netfilter
Posté par reno . Évalué à 4.
Les 'early adopters' sont important pour tous le monde: les risques qu'ils prennent permettent d'avoir un système debuggé plus rapidement, pas la peine de les dégouté avec une modif comme ça..
[^] # Re: netfilter
Posté par neologix . Évalué à 2.
Généralement, j'évite d'adopter un noyau aussi récent, mais là c'est le meilleur depuis un long moment en ce qui me concerne (correction de bugs qui trainaient depuis un moment, amélioration du pilote wifi, etc). C'est dommage que ce soit gâché par ça...
[^] # Re: netfilter
Posté par rdem . Évalué à 2.
Pour le corriger, (de tête) c'est une option dans netfilter la 3 ièeme ligne du choix dans net filter.
1° tu as l'activation ou non
2° tu as la version
3° général
4° des options spécifique je crois
Ayant fait cette modif il y as environ 12 heures, je peux pas t'en dire plus, d'autant que j'ai pas ma machine sous la main ;)
[^] # Re: netfilter
Posté par neologix . Évalué à 3.
dans mon cas, c'est le "match state" qui avait dégagé:
networking->networking options->network packet filtering framework->core netfilter configuration->nefilter Xtables support->"state" match support
Je viens de vérifier, cette option était bien activée dans mon précédent .config (2.6.19), mais a dégagé ce coup ci. Mystère...
[^] # Re: netfilter
Posté par Henry-Nicolas Tourneur (site web personnel) . Évalué à 1.
J'ai aussi du réactiver le match state cependant mes règles ne passe pas. Il drope tout (très embetant). Il m'affiche ceci lorsque je lance le script :
Quelqu'un a une idée ?
[^] # Re: netfilter
Posté par rdem . Évalué à 1.
au même endroit que le state il me semble.
[^] # Re: netfilter
Posté par Henry-Nicolas Tourneur (site web personnel) . Évalué à 1.
networking->networking options->network packet filtering framework->core netfilter configuration->nefilter Xtables support->conntrack connection tracking match support.
# Bug avec ReiserFS
Posté par Nicolas . Évalué à 2.
En utilisant ce kernel, j'ai eu le fameux problème
avec le NAT pour IPTABLES que je n'ai pas su résoudre
car je trouve que l'aide est un peu succinte....
Mais le principal problème chez moi est venu de plantages
de mon système en accédant à des fichiers ou en voulant en
supprimer : le cpu monte à 100% et tout se fige.
Donc retour au 2.6.19 et tout va bien.
[^] # Re: Bug avec ReiserFS
Posté par Julien . Évalué à 6.
Merci donc pour ta contribution au libre ...
# Xen
Posté par lurker . Évalué à 1.
What's the current state of the common parvirtualization interface that e.g. Xen depends on?
It's coming together. I'd expect support for Xen's "Domain U" function to be merged in 2.6.21 or 2.6.22.
http://fosdem.org/2007/interview/andrew+morton
Pas le domain0, certes.
[^] # Re: Xen
Posté par patrick_g (site web personnel) . Évalué à 2.
One can almost see the interest in Xen (for example) fading; KVM comes across as a much simpler, more maintainable way to support full and paravirtualization. The community seems to be converging on KVM as the low-level virtualization interface; commercial vendors of higher-level products will want to adapt to this interface if they want their products to be supported in the future.
[^] # Re: Xen
Posté par Mr F . Évalué à 2.
[^] # Re: Xen
Posté par patrick_g (site web personnel) . Évalué à 1.
Pas d'accord !
KVM est maintenant intégré en mainline alors que Xen n'est qu'un patch externe.
C'est donc KVM qui est en avance !
[^] # Re: Xen
Posté par Mr F . Évalué à 2.
Xen a un ensemble de librairies que n'a pas (encore) KVM. De plus niveau performance, Xen est pour l'instant devant.
Donc oui, Xen est en avance, l'inclusion dans le kernel ne change rien à ce niveau.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.