Sur un plan moins anecdotique le nouveau noyau propose d'intéressantes nouveautés pour les machines multiprocesseurs comme un outil de debugging spécialisé ou encore une fonction améliorée d'économie d'énergie. Les grosses nouveautés sont donc :
- lockdep : un outil de debugging qui permet de s'assurer que les verrous logiciels (lock) ne conduisent pas à une réservation infinie de la ressource. L'article de LWN sur ce sujet est particulièrement intéressant.
- priority inheritance : un outil noyau qui permet aux applications en espace utilisateur d'avoir un comportement plus déterministe. C'est utile pour le temps réel.
- SMPnice : un moyen d'augmenter et de diminuer la priorité de certains processus sur une machine multiprocesseurs.
- SATA : Une grosse refonte de l'infrastructure Serial ATA est disponible dans le noyau 2.6.18. Cela autorise le branchement à chaud (hotplug) et le réordonnancement des commandes (NCQ). De plus les performances et la gestion des erreurs sont bien meilleures.
- CFQ : L'ordonnanceur par défaut des entrées/sorties est maintenant CFQ (Complete Fair Queuing) qui permet de gérer les priorités entre les processus.
- Secmark : Un outil utile à l'infrastructure de sécurité SELinux puisqu'il permet de marquer les paquets entrants afin d'augmenter la sécurité.
- Gestion de l'énergie : l'ordonnanceur des processus est maintenant capable de gérer plus finement la gestion de l'énergie sur les machines ayant plus d'un processeur. Le fait que les ordinateurs modernes permettent de laisser un des coeurs en veille alors que l'autre fonctionne normalement est pris en compte. Ainsi au lieu de forcer la répartition des tâches sur tous les coeurs le noyau peut maintenant, si il n'est pas trop chargé, choisir de les diriger sur un seul coeur afin d'économiser de l'énergie.
- Beaucoup d'autres choses sont présentes dans le noyau 2.6.18 ainsi que des corrections de bugs, des ajouts de pilotes, etc.
Le détail (en anglais) est disponible sur la page LinuxChanges qui fait un travail formidable pour présenter à tous l'avancée rapide du plus célèbre des multiples logiciels libres.
Aller plus loin
- Les nouveautés sur le LinuxChanges de KernelNewbies (38 clics)
- L'annonce sur Kernel Trap (28 clics)
# A l'abordage !
Posté par Erwann Robin (site web personnel) . Évalué à 9.
Nomdediou, moi j'vous dit, pouvoir foutre et retirer les disques SATA sans redémarrer le bousin, ca c'est une put1** de feature comme on les aime !
ya quelque chose que j'sais pas trop à quoi qu'ca sert : c'est "Add binding/unbinding support for the VT console". Est-ce que ca fait qu'on peut enlever un TTY d'une machine et le refoutre sur une autre ?
allez, tous sur la bougresse !
[^] # Re: A l'abordage !
Posté par patrick_g (site web personnel) . Évalué à 7.
Sinon il faut noter que ce noyau 2.6.18 va sans doute être le noyau de la future Debian stable (Etch) et de la future Red Hat Entreprise Server (5.0). C'est donc une version absolument cruciale puisqu'elle affrontera Windows Vista directement au début de 2OO7.
[^] # Re: A l'abordage !
Posté par Matthieu Moy (site web personnel) . Évalué à 7.
[^] # Re: A l'abordage !
Posté par Beretta_Vexee . Évalué à 4.
[^] # Re: A l'abordage !
Posté par windu.2b . Évalué à 4.
Mais cette remarque me fait me poser une question: quelle est la politique de Debian (et des autres distribs en général) en ce qui concerne le choix du noyau à inclure par défaut? Car là, il s'agit d'un changement assez important, avec les risques que cela comporte (code jeune)... N'est-ce d'ailleurs pas trop tard pour l'inclure dans Etch?
Merci d'éclairer ma lanterne
[^] # Re: A l'abordage !
Posté par patrick_g (site web personnel) . Évalué à 3.
Kernel
======
There has been some discussions with the kernel and d-i team about the
kernel version(s) for etch. Though there is no final agreement, current
tendencies are to ship etch with 2.6.17 or newer.
The kernel will be frozen on July 30th or shortly after, but there will be
(at least) one chance to put ABI-changing kernel changes or even a newer
kernel into etch in mid of October, shortly before building the final
installer for etch. Currently, due to the massive number of local root
exploits there is some delay relative to the original time line, but it
looks like this is not going to delay the final release. We are currently
sorting that out with the kernel- and installer-team.
Donc la décision sera prise en octobre pour voir si ils passent sur 2.6.18 ou si ils restent en 2.6.17
[^] # Re: A l'abordage !
Posté par ookaze . Évalué à 2.
[^] # Re: A l'abordage !
Posté par Jllc . Évalué à 1.
J'ai de temps en temps un soucis avec mon lecteur de CD, dont le driver m'innonde brusquement de messages d'erreurs toutes mes consoles, et me laisse le lecteur HS.
Je n'ai pas réussi à comprendre la nature du problème, et je n'ai rien trouvé sur le net. Des liens sur le problème que tu évoques peuvent m'intéresser.
[^] # Re: A l'abordage !
Posté par Pierre Jarillon (site web personnel) . Évalué à 3.
Essaie d'emprunter un lecteur de CD ou même achètes-en un neuf car les prix sont très bas actuellement.
[^] # Re: A l'abordage !
Posté par ookaze . Évalué à 2.
Je fais référence à ce problème : https://wiki.ubuntu.com/Core_2_Duo_Support
Désolé, c'est en anglais.
[^] # Re: A l'abordage !
Posté par lezardbreton . Évalué à 2.
[^] # Re: A l'abordage !
Posté par clearstream . Évalué à 4.
Pour RHEL/Fedora.
Déjà, il n'y a pas de noyau par défaut car il n'y a qu'un noyau. Il y a des "saveurs" différentes (Xen ou non, PAE ou non, etc) mais ils proviennent tous des même sources.
Pour Fedora :
C'est simple, c'est la dernière mouture en prenant en compte la phase de freeze d'une release Fedora. C'est donc la dernière mouture qui est prise jusqu'à la phase test 3. Si un noyau est en RC, il sera dans la version finale (que le noyau atteigne ou non la version finale).
Pour RHEL :
C'est plus compliqué si on regarde dans le passé. Je préfère regarder ce qui se fait aujourd'hui (RHEL 4 et la sortie de RHEL 5 fin 2006 début 2007). En gros RHEL est un fork d'une Fedora (en général d'une test 2).
Au début de RHEL (nommé beta 1) il y a la dernière mouture de Linux (piquée de Fedora).
Donc au début du développement d'une version de RHEL, RHEL a ce qu'il y a de plus récent (RHEL 5 a débuté avec un 2.6.17-rc6 je crois). Par contre RHEL a plus de tests (fait par Red Hat et des boîtes "partenaires" de Red Hat) et des ajoutes de fonctionnalités qui n'ont pas leur place dans une distribution communautaire comme Fedora. Aujourd'hui FC6 et RHEL5 partage les mêmes sources.
Donc au début de RHEL il y a ce qu'il y a de plus récent et 4 à 6 mois après (donc après beaucoup de correction de bug) la version finale de RHEL sort. Evidemment, RHEL comme Fedora feront le "saut" 2.6.*-rc? vers finale si la version finale est disponible à temps.
Pour Mandriva :
En me basant sur la sortie de Mandriva Corporate Server 4.0, ils prennent un noyau éprouvé. Ici un 2.6.12 qui est probablement venu de Mandriva 2006.
[^] # Re: A l'abordage !
Posté par clearstream . Évalué à 1.
Ce n'est pas 5.0, c'est 5 (un entier).
Je confirme, ça sera dans RHEL 5. C'est actuellement un 2.6.17-rc7 mais ça passera rapidement à 2.6.18. Il y a quelques fonctionnalités de plus que le 2.6.18 et principalement une optimisation pour NFS avec cachefs. On trouve aussi les "classiques" Xen et GFS2. Il y a aussi des patchs pour contrôler/auditer le noyau (débordement, etc) mais je n'y comprend pas grand chose :-)
RHEL 5 et FC6 (actuellement les deux sont en phase de test) partage le même noyau (à quelques options de configuration près).
> elle affrontera Windows Vista
A propos de gadget, normalement AIGLX sera dans RHEL 5 (Xorg 7.1.1) et dans quasiment toutes les distributions à la sortie de Vista.
[^] # Re: A l'abordage !
Posté par clearstream . Évalué à 1.
Réponse un peu au feeling.
Lorsqu'il y a une console, il y a un driver pour cette console. Sous i386 c'est le driver VGA, mais on peut aussi utiliser le driver framebuffer.
"binding/unbinding" fait qu'on peut virer une console et la remettre. Le but étant me semble-t-il de changer de driver pour cette console.
[^] # Re: A l'abordage !
Posté par Fabien Engels . Évalué à 3.
[^] # Re: A l'abordage !
Posté par Florent Zara (site web personnel, Mastodon) . Évalué à 3.
Je suppose que le matériel (CM+DD) doit supporter cette fonctionnalité pour que cela puisse être mis en oeuvre.
[^] # Re: A l'abordage !
Posté par Gniarf . Évalué à 10.
[^] # Re: A l'abordage !
Posté par sylware . Évalué à 2.
[^] # Re: A l'abordage !
Posté par Yth (Mastodon) . Évalué à 1.
Yth.
[^] # Re: A l'abordage !
Posté par Gabriel Linder . Évalué à 5.
[^] # Re: A l'abordage !
Posté par Gabriel Linder . Évalué à 4.
(testé avec xorg 7.1, driver radeon libre et le kernel 2.6.18 tout frais)
[^] # Re: A l'abordage !
Posté par peck (site web personnel) . Évalué à 4.
(pas des VT mais des PTY). La console est un cas particulier de terminal.
La fontionnalité a été implémentée au niveau console donc uniquement sur ce qu'on obtient avec les alt-Fx
[^] # Re: A l'abordage !
Posté par Yth (Mastodon) . Évalué à 7.
Tu es sous console, avec tes atl-Fx, c'est rigolo tu t'amuses, ça marche.
Là paf, un démon malfaisant entre dans ton esprit et te pousse à faire un truc débile comme lancer un serveur X. L'impulsion est fugitive, mais un serveur X ça se lance vite, paf il est lancé, mais finalement tu n'en veux plus, tu as retrouvé tes esprits.
Donc ctrl-alt-Fx pour retourner sous console (ou ctrl-alt-backspace pour tuer le serveur X, au choix), et là beeerk, ta console est inutilisable. Ca arrive avec certains drivers, en général ça a tendance à bien marcher, mais parfois non, et je pense que ça vient du driver graphique, mais je n'ai pas poussé les recherches à ce sujet.
C'est souvent radical : la console est totalement noire et l'écran ne recevant aucune donnée fini par s'éteindre, ou alors tu restes dans un mode graphique plus élevé que celui de la console, avec tes caractères en tout petit partiellement dans une portion de l'écran, partiellement dans une autre, ça se répète vaguement et ça bugge beaucoup, ou encore tu as un mode texte normal, mais les trucs qui s'affichent ne ressemblent à rien.
Dans tout les cas, tuer tout les processus de la console ne résoud rien, en même faire un "reset" dans ton terminal n'arrange pas la situation.
Je ne connais aucun moyen de récupérer ces consoles irrémédiablement aveuglées.
Par contre le serveur X lui continue à tourner correctement, les consoles aveugles réagissent quand même donc on peut lancer des commandes, et par exemple relancer un serveur X, etc...
C'est juste qu'on ne voit rien.
Il s'agit bien ici de VT, non ?
Et donc j'avais imaginé que cette modification dans le kernel aurait pu permettre de sauver ces pauvres consoles mutilées.
Yth.
[^] # Re: A l'abordage !
Posté par Anonyme . Évalué à 1.
Je peux t'en donner un, mais il est hautement aléatoire : traiter le mal par le mal. Quelque fois, relancer un serveur X résoud le problème. Ça peut être au premier lancement, au 3ème, au 15ème (machine avec kdm). Et puis certaines fois il n'y a qu'après un rédémarrage que tout rentre dans l'ordre.
[^] # Re: A l'abordage !
Posté par peck (site web personnel) . Évalué à 5.
Je ne connais pas de technique pour récupérer une console, par contre je peux te dire comment en lire le contenu. Il suffit de lire /dev/vcsXX
/dev/vcs la console en cours
/dev/vcs1 la 1ere console
...
Si tu utilise vcsa à la place de vcs tu as droit aux caractères de controle qui vont avec (ou le contraire je ne me souviens plus).
Dans certains cas, on les trouve dans /dev/vc/
[^] # Re: A l'abordage !
Posté par un_brice (site web personnel) . Évalué à 4.
Bon, après c'est pas censé marcher, donc y'a les risques touça. Et puis je me souvient plus trop à quoi ça a pu me servir.
Mais ça marche.
[^] # Re: A l'abordage !
Posté par Yth (Mastodon) . Évalué à 3.
C'est un truc de barbare, j'en conviens, mais ça m'avais dépanné une ou deux fois, j'avais besoin d'un lecteur et je ne voulais pas éteindre la seule machine en possédant encore un chez moi.
Yth.
# SMPnice
Posté par g0d0t . Évalué à 10.
Je n'avais pas compris ça comme ça. J'avais compris que SMPnice permet de mieux répartir la charge sur chaque processeur en fonction de la charge de chaque processus, dérivée de sa priorité.
Pour éviter d'avoir 2 processus "niced" sur un processeur et 2 processus de priorité normale sur l'autre (je prends le cas d'un bi-processeur).
En tout cas je n'avais pas compris que ça change la priorié des processus, mais plutôt que ça en tient compte pour répartir les processus sur les processeurs.
[^] # Re: SMPnice
Posté par Eric Lacombe . Évalué à 4.
[^] # Re: SMPnice
Posté par patrick_g (site web personnel) . Évalué à 7.
/Mode rattrapage aux branches avec les ongles/ON
Ma description est vague mais c'était pour simplifier !
/Mode rattrapage aux branches avec les ongles/OFF
# Email de Thorvalds.
Posté par FueL . Évalué à -10.
J'ai pas tout compris dans son email d'annonce (notamment "scurvy"), mais Linus pète un peu son cable, remarque pas son 1er coup d'éclat (cf. insulte de "nazis" envers les gnomistes).
Peut-être sa façcon à lui de se détendre...
[^] # Re: Email de Thorvalds.
Posté par Damien Gombault (site web personnel) . Évalué à -5.
[^] # Re: Email de Thorvalds.
Posté par Victor . Évalué à 5.
Comme l'année dernière Linus Torvalds s'est débrouillé pour faire coïncider la sortie d'une nouvelle version du noyau Linux avec la journée internationale du langage pirate. Son annonce (signée Linus "but you can call me Cap'n") est donc assez difficilement compréhensible et pleine d'insultes ésotériques de boucaniers.
d'ou le langage plutot cheulou
[^] # Re: Email de Thorvalds.
Posté par account . Évalué à 7.
1) n scorbut m
2) adj [archaic, or liter] bas (basse f ), mesquin, vil (vile f )
s/Thorvalds/Torvalds/
[^] # Re: Email de Thorvalds.
Posté par patrick_g (site web personnel) . Évalué à 6.
Tout à fait ce qu'un capitaine pirate dirait à son équipage pour le motiver ;-)
[^] # Re: Email de Thorvalds.
Posté par yannig (site web personnel) . Évalué à 1.
[^] # Re: Email de Thorvalds.
Posté par un_brice (site web personnel) . Évalué à 10.
[^] # Re: Email de Thorvalds.
Posté par oliv . Évalué à 10.
Linus est une personne dotée d'un grand sens de l'humour, de l'auto-dérision, et capable de rédiger des emails assassins. Son coup de gueule contre les Gnomistes n'est en aucun cas son "1er coup d'éclat".
exemples (tirés de wikiquotes et de mes bookmarks):
HURD:
"In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people."
ACPI:
"The fact that ACPI was designed by a group of monkeys high on LSD, and is some of the worst designs in the industry obviously makes running it at _any_ point pretty damn ugly."
et un de mes préférés (Mach/HURD et FreeBSD):
"I claim that Mach people (and apparently FreeBSD) are incompetent idiots."
qui fut suivi de cette clarification:
"I also claim that Slashdot people usually are smelly and eat their boogers, and have an IQ slightly lower than my daughters pet hamster (that's "hamster" without a "p", btw, for any slashdot posters out there. Try to follow me, ok?).
Furthermore, I claim that anybody that hasn't noticed by now that I'm an opinionated bastard, and that "impolite" is my middle name, is lacking a few clues.
Finally, it's clear that I'm not only the smartest person around, I'm also incredibly good-looking, and that my infallible charm is also second only to my becoming modesty."
Juste pour resituer le pirate-talk day dans une longue tradition d'emails plus marrants et/ou polémiques les uns que les autres.
[^] # Re: Email de Thorvalds.
Posté par patrick_g (site web personnel) . Évalué à 5.
http://linuxfr.org/~patrick_g/21467.html
"J'affirme également que les lecteurs de Slashdot sentent généralement mauvais et qu'ils mangent leurs crottes de nez, et qu'ils ont un QI inférieur à celui du hamster de mes filles (c'est "hamster" sans "p", à propos, pour les contributeurs de Slashdot. Essayez de me suivre, d'accord ?).
De plus, j'affirme que quiconque n'ayant pas encore remarqué que je suis un batard aux opinions forgées [NDT: pas terrible, mais je trouve pas mieux, là tout de suite], et que "impoli" est mon deuxième prénom, est légèrement en retard.
Pour finir, il est clair que je ne suis pas seulement le plus intelligent ici-bas, mais également incroyablement beau, et que seule ma modestie peut se prétendre supérieure à mon infaillible charme.
Voilà. Juste pour clarifier.
Linus "faites moi une révérence, rebus" Torvalds"
[^] # Re: Email de Thorvalds.
Posté par mac_is_mac (site web personnel) . Évalué à 2.
forgées => bien trempées
[^] # Re: Email de Thorvalds.
Posté par Franck Routier (Mastodon) . Évalué à 2.
"un batard aux opinions forgées" => un bâtard borné
[^] # Re: Email de Thorvalds.
Posté par Nicolas Schoonbroodt . Évalué à 10.
Il aurait donc pu être Belge...
[^] # Re: Email de Thorvalds.
Posté par Boa Treize (site web personnel) . Évalué à 9.
En adaptation libre :
(Suite à quoi il avait tort, non pas sur Subversion ;) mais il avait mal compris ce que le demandeur voulait.)
[^] # Re: Email de Thorvalds.
Posté par Serge Hartmann (site web personnel) . Évalué à 2.
C'est une erreur de traduction et d'interprétation bien de chez nous.
Le mot "nazi" n'est pas aussi insultant en anglais qu'en français.
"interface nazis" se traduirait plutôt par "dictateurs de l'interface", dans le sens ou les développeurs de gnome prennent des décisions arbitraires quant aux besoins des utilisateurs - alors que Torvalds préfère offrir plus de choix et d'options aux utilisateurs.
[^] # Re: Email de Thorvalds.
Posté par Elrik de Melnibone . Évalué à 2.
On peut dire que les gnomistes sont des dictateurs de l'interface, mais qu'ils prennent des décisions arbitraires, c'est vraiment diffamatoire !
[^] # Re: Email de Thorvalds.
Posté par eloi . Évalué à 1.
Je confirme pour arbitraire rien que pour le support multi-users de gvm (pam_console (redhat) et non pam_foreground (debian & lfs))...
Au propos du "sujet":
le 2.6.18 apporte un bien meilleur support pour les mac intel (macbook), (toujours avec les patch mactel), j'ai moins de freeze du disque sata (assez désagréable).
[^] # Re: Email de Thorvalds.
Posté par Crazy_Warthog . Évalué à 5.
rah c'est bon..
désolé
[^] # Re: Email de Thorvalds.
Posté par Sylvain Briole (site web personnel) . Évalué à 6.
Je ne suis pas un pro de la linguistique, aussi j'aimerais bien avoir un éclairage sur ce point....
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Email de Thorvalds.
Posté par mdlh . Évalué à 5.
C'est contextuel et des fois le terme nazi est bien utilise comme on l'entend en France. Cf utilisation du mot Nazi par les opposants de Bush.
On peut aussi remarque qu'ils n'ont connu aucune guerre sur leur sol
Ils ont reclassifier la guerre d'independance et la guerre de cessession en "promenade dans les champs"?
Ils se sont pour la premiere fois de leur histoire senti agresser et donc ils reagissent en mode reflex d'autodefense.
Y a quand meme eu un "petit petard" au WTC en 93. Pour ce qui est du reflex d'autodefense, c'est pas nouveau et pas propre au 11 Septembre. Coree, VietNam, Guerre froide, Cuba... Certes, ils sont passe a la vitesse superieur depuis le 11 Septembre.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Email de Thorvalds.
Posté par patrick_g (site web personnel) . Évalué à 10.
C'est bien de répéter ce que tu lis dans les journaux mais faut songer à se documenter avant de dire des bétises. Les USA ont bien connu la guerre sur leur sol en plus de la guerre d'independance et la guerre de secession.
C'est la guerre de 1812 contre les anglais.
On en parle pas souvent car à l'époque l'Europe était en plein dans les guerres napoléoniennes.
A noter que les anglais ont bien envahi le territoire des USA puisqu'ils ont brulé la maison blanche et que le President James Madison a été forcé de s'enfuir de Washington !
En français (pas complet) : http://fr.wikipedia.org/wiki/Guerre_de_1812
En anglais (plus complet) : http://en.wikipedia.org/wiki/War_of_1812
Moralité : le journalisme c'est bien mais la fac d'Histoire c'est mieux.
[^] # [HS] L'ennemi c'est les autres ou la guerre à l'étranger
Posté par Benoît Sibaud (site web personnel) . Évalué à 5.
- Perl Harbor c'était leur sol aussi (même si c'était une base militaire hors « métropole » états-unienne)
http://en.wikipedia.org/wiki/Perl_Harbor
- D'ailleurs pour chipoter encore plus, leurs ambassades attaquées dans leur « guerre contre le terrorisme » (suivant leur terminologie) sont aussi leur sol, où qu'elles soient sur la planète.
Mais bon on va pas quadrisectionner les cheveux sur des hors-sujets non plus.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Email de Thorvalds.
Posté par patrick_g (site web personnel) . Évalué à 5.
[^] # Re: Email de Thorvalds.
Posté par mdlh . Évalué à 0.
On peut chipoter mais pour ce qui est de la guerre de cessession, les etats du sud ne faisait plus partis de l'union. C'est d'ailleurs pour cela qu'apres la fin des combats, il a fallut les "reintroduire" dans l'union. Il y a eu tout un debat sur la definition des criteres permettant ces etats
de oui ou non refaire partie de l'union. Puisqu'apparement tu es aux US, tu peux surement obtenir un "textbook" de l'histoire des US a ce sujet si tu as une universite pas trop loin. Attend le debut du prochain semestre. Il en reste toujours un peu a la librairie de l'universite et generalement ils sont en solde.
La guerre du vietnam, la plupart des americains ne savent toujours pas ou c'est sur une carte...
Ca c'est un super critere qui tue pour definir si on se sent attaque ou pas. Plus serieusement: Oui le 11 Septembre a ete ressentit comme une attaque. Y a pas de doute possible. Je dis juste que c'est pas la premiere fois. Pour ce qui est des sentiments que tu evoques et la methode "lance flamme", je crois que ca correspond a ma definition de "vitesse superieure".
[^] # Re: Email de Thorvalds.
Posté par popopo333 . Évalué à 3.
je me demandais... parmi les etats uniens incapables de situer le vietnam, combien savent situer new york?
[^] # Re: Email de Thorvalds.
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
Bref, le monde est loin dêtre parfait, ni d'un coté, ni de l'autre coté de l'atlantique ;-)
Au niveau de la guerre, les japonais ont atteint l'île de Kodiak en Alaska pendant la guerre... ïle qui était l'ancienne capitale de l'Alaska au temps ou c'était encore la Russie. A l'époque, ils ont eu si peur qu'ils ont fait LA Route qui passe par le canada pour expluser les japonais....
Bon OK, L'Alaska is the last frontier et il n'y a pas grand monde...
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Email de Thorvalds.
Posté par Guillaume D. . Évalué à 1.
http://video.google.com/videoplay?docid=6302880871177953720
a mediter .
[^] # Re: Email de Thorvalds.
Posté par reno . Évalué à 3.
En Anglais c'est une série de discussion sans fin car c'est une langue assez "souple" avec des variantes proposée..
Evidemment on a les mêmes en France, il n'y a qu'a voir le stupide tollé qu'a cause la réforme de l'orthographe, mon royaume pour un accent circonflexe!
Donc 'grammar nazi' --> 'interface nazi', ce qui est une bonne caricature de Gnome: 'obsédé de la forme des interfaces par rapport au fond'.
[^] # Re: Email de Thorvalds.
Posté par Jeanuel (site web personnel) . Évalué à 3.
La bonne traduction de interface nazi serait dont assez proche de interface fasciste...
[^] # Re: Email de Thorvalds.
Posté par LeMagicien Garcimore . Évalué à 10.
Je vote plutot pour Fasciste de l'interface
[^] # Re: Email de Thorvalds.
Posté par FueL . Évalué à -9.
Quel châtiment, bon c'est bien beau de parler de liberté d'expression et tutti quanti, quand je vois que le fait d'ouvrir un tant soit peu sa gueule sur linux.fr conduit souvent à se faire vilipender en place public...
Ça aurait été cool au moins pour le fil de la discussion, et un peu par honnêteté intellectuelle de laisser mon post au moins juste à zéro, pour connaître le point de départ et l'objet de la discussion...
Mon comm n'avait rien d'incendiaire ou de trollesque je pense, c'était juste une constation, mais je m'apperçois de plus en plus que pour peu qu'on s'éloigne de l'avis commun c'est forcément dénigrement (par notation négative) ça me dérange pas qu'on partage pas mon avis, mais que le moinssage devienne systématique us dès qu'on parle d'une autre voix je trouve ça triste pour ce forum...
Ce 'forum' a d'ailleurs perdu de sa convivialité je trouve...
Enfin bon je sais que ce commentaire ne changera rien, mais dorénavant je m'abstiendrai, c'est beau la diversité prônée par tant de personnes qui viennent ici et qui ne l'appliquent pas à eux-mêmes ou aux autres...
Ciao.
[^] # Re: Email de Thorvalds.
Posté par patrick_g (site web personnel) . Évalué à 3.
Putain mais ça t'importe tant que ça le score de tes commentaires ?
Je te signale humblement qu'à mon avis 90% des gens n'en ont rien à foutre et que la majorité des lecteurs surfe avec un seuil à -42 afin de voir tous les posts.
Ne te fait donc pas de souci pour la visibilité de ta prose.
[^] # Re: Email de Thorvalds.
Posté par FueL . Évalué à -10.
Je me lustre pas la hampe avec mes scores de comm' pr ta gouverne...
Je me cite :
"Ça aurait été cool au moins pour le fil de la discussion, et un peu par honnêteté intellectuelle de laisser mon post au moins juste à zéro,"
C'est pas tant le score qui m'imporet si tu lis, mais le moinssage systématique dont font preuve certains, y'a des fois c'est fondé, mais quand comme je le redis : ça devient systématique c'est juste reloud. Et quand on ne sait même plus le départ de la discussion, ça l'est encore plus, ce que je dis là est valable pr moi bien sûr, mais j'ai remarqué ça sur d'autres postes que je trouvais plutôt injustement malusé...
Ca sert à rien de t'emporter pr si peu...
[^] # Re: Email de Thorvalds.
Posté par patrick_g (site web personnel) . Évalué à 5.
Tu a compris ce que j'ai écrit sur le seuil de -42 ?
La grande majorité des lecteurs voit tes posts même quand ils sont en négatif !
Et pour les autres ils peuvent facilement déplier ton post pour le lire si ils le veulent.
De façon générale cela ne sert à rien de chouiner sur les moinssages et sur la cabale qui s'acharne sur toi. C'est même un peu puéril AMHA.
[^] # Re: Email de Thorvalds.
Posté par left . Évalué à -5.
[^] # Re: Email de Thorvalds.
Posté par patrick_g (site web personnel) . Évalué à 3.
D'ou l'utilité de régler son seuil afin de ne plus jamais avoir à déplier quoi que ce soit !
http://www.flickr.com/photo_zoom.gne?id=166526247&size=o
[^] # Re: Email de Thorvalds.
Posté par fox (site web personnel) . Évalué à 1.
[^] # Re: Email de Thorvalds.
Posté par Jean-Philippe (site web personnel) . Évalué à 8.
[^] # Re: Email de Thorvalds.
Posté par fox (site web personnel) . Évalué à 2.
[^] # Re: Email de Thorvalds.
Posté par François LEIBER (site web personnel) . Évalué à 1.
[^] # Re: Email de Thorvalds.
Posté par lolop (site web personnel) . Évalué à 4.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Email de Thorvalds.
Posté par Jacquot Raphael . Évalué à -1.
c'est "Torvalds"...
bien qu'il soit nordique, rien a voir avec Thor ( http://fr.wikipedia.org/wiki/Thor ) ...
# BTTV ????????????
Posté par beck . Évalué à 1.
[^] # Re: BTTV ????????????
Posté par Rin Jin (site web personnel) . Évalué à 2.
[^] # Re: BTTV ????????????
Posté par aurelj . Évalué à 7.
Par contre il dépend maintenant de l'option V4L1, donc effectivement tant que tu ne selectionne pas cette option, le driver bttv semble avoir disparu.
[^] # Re: BTTV ????????????
Posté par Frédéric COIFFIER . Évalué à 2.
Vu que V4L1 est obsolète maintenant...
# Question sécurité ?
Posté par skeespin (site web personnel) . Évalué à 2.
[^] # Re: Question sécurité ?
Posté par Undefined8000 . Évalué à 2.
# Auto chargement de code optimisé
Posté par Dafatfab . Évalué à 4.
J'espere m'etre fait comprendre car je ne sais pas le nom exact de cette "feature"... qu'en est il ?
[^] # Re: Auto chargement de code optimisé
Posté par neologix . Évalué à 6.
http://lwn.net/Articles/164121/
Ca a été implémenté dans le 2.6.17.
[^] # Re: Auto chargement de code optimisé
Posté par Dafatfab . Évalué à 1.
Ca s'appelle donc "SMP "alternatives" for x86-32." :-)
[^] # Re: Auto chargement de code optimisé
Posté par clearstream . Évalué à 2.
Pas vraiment :-)
Ce qui est dit au-dessus est exacte. Mais tu dois faire référence à autre chose qui a été implémenté il y a longtemps.
La fonctionnalité est de fournir un noyau optimisé pour i586 et K7 par exemple. Au boot, le noyau détecte le cpu et utilise les fonctions optimisées pour le cpu.
# priority inheritance... encore un pas de plus :)
Posté par bubar🦥 (site web personnel) . Évalué à 4.
le temps-réel avance petit à petit, et il n' est pas exlu que " ... soon real-time could become more widespread. Seiler believes Molnar's patch will be accepted soon into the mainstream Linux kernel"
ce qui serait vraiment Royal. S' il était complètement intégré (complètement, je ne sais pas puisqu' une horloge hrt à fait son apparition en juin, et qu' il -me- semble que le patch de Sir Molnar en a une aussi, donc... bon bref l' essentiel ;) ) cela permettrai de très facilement avoir un kernel "preemption on acid".
Même en partant d' un kernel patché à mort comme celui d' une mandriva ou d' une suse ! Il suffirait de choisir l' option "full preemption" (comme aujourdhui on peut choisir entre la preemption volontaire et "outofbox", plutôt que le choix par défaut, dit "server"). -aussi les options "rtc clock par défaut et en dur" et 1000hz bien sûr.. au fait hpet on garde ou pas ? ;) - Un kernel comme celui d' une SuSe ou d' une Mandriva, bien complet, avec full support hardware, mais en realtime complet juste en recompilant (et en mettant au diapason PAM pour l' audio) = le bonheur total...
Bon je veux pas envoyer de pathfinder sur Mars, c' est sûr. Ni faire des missiles intelligents. Non plus hacker mon futur aldebaran-robotics... non juste pouvoir avoir un kernel qui permette de faire du son, sans lag aucun, parfaitement prévisible, et au dessus de tout ce qui se fait aujourdhui...
Les GNU de LAUD se défoncent pour faire des applis de feu (ardour, rosegarden, jamin.... toutes les autres). Un tel kernel serait la cerise sur le gateau. Facilement accessible pour tous puisque l' option serait intégrée par défaut (et non plus prendre le patche sur people~mingo et l' appliquer au vanilla, mais se servir direct des kernels de nos chères distribs).
Gain co-latéral ? que, enfin, Jack, décolle et s' impose... (pas seulement pour les pro du son)
/troll : parcequ' y en a marre des arts / esd / phonon / pusleaudio .... /troll
(et hop...)
[^] # Re: priority inheritance... encore un pas de plus :)
Posté par bubar🦥 (site web personnel) . Évalué à 3.
Et Mandriva est totalement pré-configurée pour le Son (il faut juste se faire le kernel)
du côté de RedHat (the master of) c est RedHawk.. et en trollant on peut se demander ce que penses Concurent-soft de la possible intégration par défaut de ce patch.
(les autres projets, hyperviseurs, sheduleurs et autres choix de micro noyaux ne seront pas impactés, mais concurent-soft et certains fournisseurs de services..si certainement)
[^] # Re: priority inheritance... encore un pas de plus :)
Posté par Eric Lacombe . Évalué à 4.
Les hrtimers n'ont rien à voir avec l'horlogoge système. Pour le reste tu dois faire référence au patch dyntick d'ingo Molnar et Ted T'so.
Régler la fréquence d'horloge à 1000Hz n'est pas forcément une bonne idée car le temps passé à gérer l'interruption du timer prend une part non négligeable du temps processeur. HPET est une infrastructure très intéressante, d'ailleurs si ta CM à ce type de matos il est justement utilisé en prio (si tu l'as activé dans les options du noyau) pour l'interruption du timer...
Un truc intéressant sinon est bien le patch dyntick qui propose du tickless ou du tick variable (cependant plutôt pour le domaine de l'embarqué par rapport à la conso énergétique).
Si par realtime complet tu entends hard real time, je doute que cela soit le bonheur total pour une utilisation "poste de travail" où l'interactivité avec le système est un aspect important. Le hard RT garanti (de façon mathématique) les latences max, au détriment de l'intéractivité justement.
[^] # Re: priority inheritance... encore un pas de plus :)
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Il y a longtemps j'avais créer un benchmark avec des taches qui tournaient autour de la seconde... Sur une même machine en idle, je pouvais avoir 30% de variation sur le temps d'execution ...
"La première sécurité est la liberté"
[^] # Re: priority inheritance... encore un pas de plus :)
Posté par Eric Lacombe . Évalué à 2.
[^] # Re: priority inheritance... encore un pas de plus :)
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Si tu utilises un truc bête à priorité dont tu peux prédire le comportement qu'avec 2 ou 3 process au desssus, bonne chance...
"La première sécurité est la liberté"
[^] # Re: priority inheritance... encore un pas de plus :)
Posté par Eric Lacombe . Évalué à 0.
[^] # Re: priority inheritance... encore un pas de plus :)
Posté par Eric Lacombe . Évalué à 1.
[^] # Re: priority inheritance... encore un pas de plus :)
Posté par crabs (site web personnel) . Évalué à 1.
Un avis perso, si le système devient temps réel, tous les appels système pourront
être préempté - ce qui est loin d'être le cas actuellement.
Donc fini les machines figées, et bonjour les chiens de garde. Maitenant reste à savoir
si les concepteurs de carte mère fournirront des chiens de garde utilisables par un
noyau libre...
Perso travaillant pas mal avec Solaris sur des plateformes SUN, il est agréable d'avoir
des compteurs de secondes qui ne dérapent jamais... Le même code (développé avec
QT de trolltech) porté sur plateforme Intel / Gnu-Linux ne fournissent pas le même
résultat.
[^] # Re: priority inheritance... encore un pas de plus :)
Posté par Eric Lacombe . Évalué à 1.
Maintenant dans certaines parties la préemption est désactivée, il reste encore quelques "noyaux durs" à supprimer, mais dans l'ensemble c'est fait.
[^] # Re: priority inheritance... encore un pas de plus :)
Posté par bubar🦥 (site web personnel) . Évalué à 5.
-> il ne s' agit pas de la même chose, je pense que tu le sais. C' est un module temps-réel (un linux security module) ce qui est différent d' un kernel preemption on acid
grosso modo par défaut on est en "temps partagé"... L' ordonnanceur a pour but un partage des ressources équitables entre les process. On peut jouer sur la priorité d' un process parmis l' ensemble grâce à la "nice"
sur un système dit temps-réel, on aura des taches qui auront un comportement dans des notions précises de temps défini. Le vrai terme "système temps-réel" pourrait être "système prédictible". C' est à dire que l' écriture, le traitement et la restitution de l' information sont effectuées dans un temps si faible que l' on nomme cette information comme étant "information préservée".
Maintenant sur Linux, il y a plusieurs solutions de "temps-réel" (terme un peu fourre tout de manière générique mais on devrait définir par lui des choses plus précises, ici). Et tuons de suite le troll "ouaihg je joue a WoW en temps réel c est plusse mieux ça va plusse vite"... Non : un système temps réel, en consacrant de hautes priorités (et une mémoire dédiée) à certaines tâches, réduit les ressources disponibles pour l' ensemble. Un système temps-réel sur un bureau, comme le dit Eric L, est synonime d' amoindrissement des ressources pour l' utilisation bureautique et mulimédia classique du comput'...
Il existe deux types de temps-réel :
le temps-réel dur et le temps réel mou.
Les deux solutions présentées par défaut dans tout kernel sont toutes des "temps-réel mous". C' est à dire qu' une certaine souplesse ai accordé aux tâches ayant pourtant accès à la priorité temps-réel (c' est à dire concrètement qu' il n' est pas interdit qu' elles dépassent 25millisecondes sir 25 est la définition du système rt)
1. le patch "preemptif" de Mr Love : il agit sur l' ordonnanceur et réduit le temps de réponse de manière systématique. (c' est également la solution de MontaVista, pour lequel Mr Love travaillait)
2. le patch "low-latency" de Mr Morton : il agit seulement sur des points précis du noyau, alors appelés "points de preemption" et ne s' occupe que de latence sur ces noeuds là.
Quant au patch de Sir Molnar, il transforme le noyau linux en noyau preemption on acid (c' est à dire en noyau à capacités temps-réel dur). Un watchdog (dont Eric L parle également ici) tournant en temps-réel se chargeant de la sécurité. Et c' est bien ce patch (peut-être amputé de son horloge) qui pourrait peut être rejoindre les 2 précédents et être intégré par défaut, et accessible du coup sur tout kernel de toutes distrib, juste en recompilant ! (pour notre plus grand bonheur)
Une fois ce type de noyau préparé, l' administrateur doit indiquer au système de sécurité quels utilisateurs et/ou groupes d' utilisateurs auront droit d' accès à ces capacités. Sur une distribution "moderne" (aucune idée de troll) c' est bien sûr PAM qui s' en charge. (et sur une distrib vraiment moderne et pas seulement à la mode, c' est pré-configuré /troll!)
Voilà voilà.
on pourrait parler du fameux Xenomai et de son micro-noyau hyperviseur qui fait tourner le noyau linux en tache. (Xenomai issu de de rtai lui même issu de rtlinux)
ou encore "flamer" sur wince, annoncé comme révolutionnaire (windows c.e embarqué et temps-réel) mais... personne en veut, encore plus depuis qu' ils ont ouvert leurs sources... le machin est cantonné aux gadgets genre téléphone portables... mort de rire :)
note inutile : ze devrais sortir dans pas longtemps un howto (bien humble) sur comment transformer facilement sa mandriva en diva-linux, pour péter les solutions actuelles grâce au travail des LAUD ... Et mettre en avant la qualité actuelle des solutions de traitment du signal audionumérique sous GNU/Linux... (troll : Apple ils vont pleurer longtemps pour le port Jack sur osX ;-) ? le site .com est sorti pourtant /troll) Si des gens lisant ceci sont éventuellement intéressés, ils peuvent m' envoyer un message privé. Toutes corrections/relectures/engueulades/merci/conseils/éclairage-de-gurus sont les bienvenues.
[^] # Re: priority inheritance... encore un pas de plus :)
Posté par Eric Lacombe . Évalué à 2.
-> il ne s' agit pas de la même chose, je pense que tu le sais. C' est un module temps-réel (un linux security module) ce qui est différent d' un kernel preemption on acid
Quand je disais ça je répondais uniquement à Christophe Cazajus :
tous les appels système pourront
être préempté - ce qui est loin d'être le cas actuellement.
-----------------
Sinon quand tu dis "un module temps-réels (un linux security module)", il n'y a strictement aucun rapport entre un LSM et le temps réel.
La péemption en mode noyau est une caractérisque commune aux noyaux RT. Les patchs de Love, Morton, permettent justement cela (on a soit un appel direct au scheduler par les tâches soit c'est en sortant de certains chemins noyau (ex. retour en usermode, etc.)) que le flag NEED_RESCHED (positionné lors du traitement d'une interruption par ex) est testé et s'il est positionné, on fait appel au scheduler.). Ensuite, il y a beaucoup d'autres choses à modifier afin d'obtenir un noyau RT dur, et c'est ce à quoi se démène Ingo et Ted (préemption des spinlocks, etc.). Bref...
Le vrai terme "système temps-réel" pourrait être "système prédictible"
Ce n'est pas suffisant, il faut la propriété de déterminisme également.
Un watchdog (dont Eric L parle également ici) tournant en temps-réel se chargeant de la sécurité.
C'est un certain Christophe Cazajus qui parle de watchdog...
sinon le watchdog se charge de la sûreté de fonctionnement (safety) et _non_ de la sécurité au sens security !!!
Les deux solutions présentées par défaut dans tout kernel sont toutes des "temps-réel mous".
ben non... (par ex. VMware s'est pour du RT dur). Encore une fois, le temps réel est dit dur lorsque l'on a besoin d'avoir des _garanties_ sur les _échéances_ (Le temps de traitement peut très bien être important, ça dépend du système à piloter). Et ces dites garanties doivent être prouvées mathématiquement (RMA, etc.). Le RT mou est quant à lui adapté pour les traitements audio ou vidéo, car une garantie au sens math n'est pas nécessaire (il n'y a pas risque de mort)...
Bref, il ya beaucoup de chose à dire... En tout cas il n'y a pas d'intérêt d'avoir un Linux patché RT dur pour une station de travail (c'est hors propos)..
[^] # Re: priority inheritance... encore un pas de plus :)
Posté par bubar🦥 (site web personnel) . Évalué à 2.
ok également pour "le temps de traitement peut très bien être important, ça dépend du système à piloter", ma phrase en ne parlant que de "minima" était réductrice. (bien que le minima soit plus souvent recherché)
mais une question sur le temps réel "mou" : tu le dit adapté au traitment audio et/ou numérique : alors pourquoi sur un rt mou j ai des xrun bien plus souvent que sur un rt dur ? (et sans entrer dans un "bah tel patch est pas bon" loin de moi l' idée de juger ces travaux)
En plus de nombeux exemples de solutions professionnelles en Vidéos sont RT dur (et pas seulement en diffusion/streaming, mais aussi en étalonnage, ce qui m' a d' ailleurs étonné)
dernier mot
" flag NEED_RESCHED (positionné lors du traitement d'une interruption par ex) est testé et s'il est positionné, on fait appel au scheduler.). Ensuite, il y a beaucoup d'autres choses à modifier afin d'obtenir un noyau RT dur, et c'est ce à quoi se démène Ingo et Ted (préemption des spinlocks, etc.). Bref..."
tu aurais pas écrit une doc sur le sujet ou un bon rtfm à me pointer ? (même si c' est pas en rapport direct avec le son, cela m' intéresse fortement)
Merci
[^] # Re: priority inheritance... encore un pas de plus :)
Posté par Eric Lacombe . Évalué à 2.
Il y a également cela (2.6.8.1): http://josh.trancesoftware.com/linux/linux_cpu_scheduler.pdf
[^] # Re: priority inheritance... encore un pas de plus :)
Posté par Damien . Évalué à 2.
Pas la peine de troller, le port existe deja depuis pas mal de temps.
http://jackaudio.org/download
Il y a meme une version speciale multiprocesseur pour MacOSX
http://lac.zkm.de/2005/proceedings.shtml#letz_et_al
et
http://www.grame.fr/Research/list.php?type=ARCH
[^] # Re: priority inheritance... encore un pas de plus :)
Posté par bubar🦥 (site web personnel) . Évalué à 2.
Eric L >> Régler la fréquence d'horloge à 1000Hz n'est pas forcément une bonne idée car le temps passé à gérer l'interruption du timer prend une part non négligeable du temps processeur
hum très intéressant. faudra que je me penche, plus, sur ce sujet précis et que je fasse des tests entre 2 noyaux sur mon tit matos. Aurais tu un bon rtfm à me pointer ?
question hardware :
Ma prochaine carte mère sera celle-ci (enfin quant j aurais du pognon) :
http://www.radisys.com/products/datasheet_page.cfm?productda(...)
et pour la carte son, j hésite entre une française très bien supporté par Linux:
http://www.digigram.com/pdf_manual/soundcards_comparison_cha(...)
et une autre dont les (au moins un) dev. de la boite participe directement upstream a Alsa :
http://audioscience.com/internet/products/sound_cards/asi661(...)
(pour changer des hammerfaul et autres grandes classiques du nux...)
[^] # Re: priority inheritance... encore un pas de plus :)
Posté par Eric Lacombe . Évalué à 1.
(je te rappelle également que la valeur par défaut sur 2.6 est depuis déjà qq temps, positionnée à 250Hz).
[^] # Re: priority inheritance... encore un pas de plus :)
Posté par iug . Évalué à 1.
Du coup si un thread RT tebouffes 99% du CPU alors tu perds toute interractivité avec les autres applications.
Par contre si un thread RT te bouffe 1% de CPU, et ben tu vois pas la différence. Style si tu utilises Jack pour faire du son tu es dans ce cas et là c'est du bonheur.
# bug corrigé dans l'emulateur de term
Posté par Jacquot Raphael . Évalué à 3.
après avoir galéré 3h, j'ai trouvé qu'il fallait mettre
export NCURSES_NO_UTF8_ACS=0
dans un /etc/profile quelconque, sinon, on a pas les caracteres en forme de boites...
[^] # Re: bug corrigé dans l'emulateur de term
Posté par bubar🦥 (site web personnel) . Évalué à 2.
pas ce problème ici, sur aucune console tty ou emulateur de term
une distro tout en utf8
2.6.18-rt3 #blabla
ncurses 5.5
# Nouveau pépin et SAA7134
Posté par VoixOff . Évalué à 3.
Dans le dernier noyau, 2.6.18, le module tda9887 n'existe plus en tant que tel.
Ça nécessite de modifier les options des modules (/etc/modprobe.d ou équivalent) pour avoir un son correct.
Avant : options tda9887 qss=1
Après : options tuner qss=1
# bcm43xx: grosse régression
Posté par neologix . Évalué à 3.
Juste pour vous dire que si vous utilisez ce pilote, un bug a été introduit dans le 2.6.18, qui freeze le système au bout de quelques minutes/heures.
Je cite l'e-mail d'un développeur:
Apparemment, un problème de synchronisation:
# Wifi sur Amilo
Posté par munshausen . Évalué à 2.
J'ai contacté le développeur, Marcel Naziri (très sympatique au demeurant), et il a mis à dispo une mise à jour sur son blog, v0.5.0.
Son projet sert à activer/désactiver la radio de la carte wireless sur les Amilo M7400, et il fonctionne également sur ma machine Amilo A1650G.
http://linuxfr.org/~munshausen/22729.html
# Et dans la discrétion...
Posté par tipote . Évalué à 7.
Pour rappel, il avait d'abord été retiré complètement parce qu'il contenait un module binaire pour le protocole de décompression depuis la webcam. Puis il avait été réintégré après avoir enlevé le module binaire, mais ne supportant plus les hautes résolutions par la même occasion. [1]
Pour ma webcam pcvc840 (Philips Toucan II), ce module réintégré ne me donnait que du gris, mais point d'image...
Dans le même temps, Luc Saillard développait une alternative [2].
Dans le noyau version 2.6.18, le numéro de version du pilote pwc (1.0.12) correspond à la dernière fournie par Luc. À la lecture des sources, il semble que même le code de décompression (open-source cette fois) a été intégré. Ma webcam me fournit une image maintenant !
Au départ, les version fournies par Luc avaient été critiquées parce qu'on avait supposé qu'il avait décompilé le binaire original plutôt que procédé par ingénieurie inverse. Cette supposition vient des tables de décompression que contient le pilote. Les sources contenues dans le noyau 2.6.18 contiennent ces tables, mais elles expliquent comment les obtenir mathématiquement, et pourquoi on les utilise (pour des questions de performances). Le doute semble donc être levé.
Profitez bien de la vidéo-conférence ! [3]
[1] http://linuxfr.org/2005/05/31/19026.html
[2] http://www.saillard.org/linux/pwc/
[3] http://tipote.free.fr/ekiga.png
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.