ThE_TemPLaR :
Un changement, et tout peut casser.
Mouais… La théorie et la pratique…
Ben, un changement dans le kernel et cdrecord doit être revu.
Le logiciel cdrecord, n’est pas une merveille mais c’est une application clef pour certains.
J’ai aussi vécu l’époque ou l’ACPI marchait une update sur deux, donc oui, un changement, et on a parfois son système en moins.
Y’a pas longtemps, avec les kernels 2.6.6, c’était carrément la couche USB qui avait pris un coup dans la tronche.
Le monolithique a ce gros défaut et il ne peut pas être renié.
Oui, mais quand on parle de “refaire” on ne parle pas des applications user land. Là de toutes façon, ça ne dépend que des API proposées. Si l’api change, quelque soit l’architecture du noyau, les application l’utilisent changent.
Par contre là ou c’est “censé” améliorer les choses, c’est lors d’un changement d’architecture du noyau, comme le passage à ia64 ou les 2schedullers du 2.6
Mais là, c’est plus théorique que pratique quand même.
Perso, ça m’intéresse pas mal si on arrrive à réduire les latences dans le 2.6…Le patch low latency a été refusé dans le cycle de dével du 2.5 mais j’aimerais assez le voir revenir. Linux n’est pas un OS temps réel mais dans certains cas, les latences sont trop longues…
v_atekor : En tout cas, les répercussions de quelques changements se manifestent chaque 2 versions, ça devient vraiment ‘chiant’ étant donné que cette version, bien qu’en développement, fait partie de la branche “stable”.
On a vraiment l’impression qu’à chaque ajout, une partie s’en prend un coup…
Enfin bon, tant qu’on a que ça de viable, on va pas trop cracher dessus…
Templar : je sais 
Mais c’est plus un problème de tests et de … se mettre d’accord sur une api claire!
fakbill : Il y a du travail pour le rendre temps réel…
sinon jettez un oeil sur ça: ça ne vous rappelle rien ?
http://linuxtoday.com/news_story.php3?ltsn=2004-09-20-003-26-OS-DV
Oui, Linux n’a pas été conçu pour être temps réel “dur”. Cela dit, pour certaines appli, on peut se contenté un “temps réel non garanti”, cad d’une bornes sup garantie et acceptable sur temps de latence.
Les schedulers…une longue histoire 
Cool… Le problème (fameux) avec le fsync ne vient pas de NFSv4 mais de … ext3 :??: que de temps perdu. Et en plus se faire pourrir sur les mailing lists! 
Bon, bonne chose de faite!
v_atekor > tes machines de test n’utilisent que ext3 ? les performances seraient différentes avec un rfs non ?
Probable. Mais je teste NFS et pas le reste. Peu importe que le reste du système ait de mauvaises performances, le tout, c’est que mes tests soient cohérents, et reproductibles, que les perfs augmentes… et que les performances à travers le réseaux soient proches des performances locales, même si en local elles sont mauvaises.
Pour la reproduction des tests, mieux vaux ext3, et comme j’ai commencé avec de ext3, je ne peux pas passer à xfs ou reiser3 [même si je vais y passer si les bugs de ext3 mettent trop de temps à être résolus]
Les gens d’ext3 sont prévenus je suppose. Qu’en disent ils?
Ils bossent dessus. En tout cas ils le disent.
finalement, les fichiers d’un kernel, quand on compile, ils s’installent où ? :??: (à part les modules qui sont dans /lib/modules/ je crois)
parce que pour supprimer un kernel installé en rpm, ok, mais pour supprimer ‘proprement’ un kernel compilé manuellement on fait comment (à part supprimer à la barbare les modules et enlever les entrées dans grub.conf) ?
rm -rf /usr/src/kernelxxx pour les sources
rm -rf /lib/modules/linux-version/
rm -f /boot/vmlinuz-version (ou vmlinubz ou bzImage, ou …)
rm -f /boot/config-version (la config du noyau, souvent on la sauvegarde là)
rm -f /boot/System.map-version (je crois que ça ne se fait plus baucoup ça, et si oui, il y a un liens symbolique System.map qui pointe vers celui du noyau utilisé)
“Ils bossent dessus. En tout cas ils le disent.” : On a vu passer pas mal de patchs ext3 il y a peu. Ils disaient que c’était, entre autre, pour virer certains locks non nécessaires…c’est liéà ton pb?? (Je n’ai pas eu le temps de regarder les diff.)
pareil
noyau est config pour moi
perso je fais un make install, donc binaire + system.map + config =)
en fait c’est ce que je faisais, mais j’avais peur qu’il reste des fichiers qq part que j’avais pas vu, et qui m’aurait bouffé mon espace disque sans savoir pourquoi
mais maintenant je suis rassuré :jap: :jap: