Un petit dernier qui commence a ressembler a quelque chose de bien:
rawstudio
Libre, basé sur dcraw pour la partie decodage du raw, le reste de la chaine de traitement est faite maison, optimisée MMX/SSE/3DNow! pour Intel/AMD 32/64bit.
> CFS a eu les faveurs de la communauté pour plusieurs raisons:
> 1- Il est jugé techniquement supérieur
Son design fait intervenir des structures plus complexes a manipuler que le Staircase Deadline (SD). Si bien qu'il ajoute des lignes de code a sched.c là ou SD en enleve et le rend plus simple a maintenir.
> 2- Ingo Molnar est capable de travailler en équipe et d'accepter les contributions d'autres personnes à "son bébé". Il suffit de regarder les changelogs de CFS pour voir que de nombreuses améliorations ne sont pas de lui. Dans un projet aussi communautaire que linux, c'est fondamental (cf. la situation de la couche IDE des noyaux 2.0, 2.2).
Ingo est un vieux routard du noyau, il a une aura dans la communauté LKML qui attire beaucoup plus qu'un pauvre gars, même pas informaticien qui tente de convaincre son monde depuis bientot 5 ans au travers de patchs toujours refusés upstream faute de consensus/perseverence.
> 3- Ingo Molnar lance un projet et le maintient ou bien lui trouve un autre mainteneur (le dernier noyau realtime a été annoncé par Thomas Gleixner qui à l'origine était un petit contributeur, et maintenant est le principal contributeur de ce patch). Quelques temps après avoir créé SD, Kolivas a du s'arrêter de développer pour des raisons de santé. C'est ce qui a poussé Ingo Molnar à lancer CFS. Il n' y avait personne qui pouvait/voulait continuer le travail de Con Kolivas. C'est important d'avoir l'assurance que tel ou tel projet sera maintenu.
Faux, CFS n'est pas du au retrait de Con Kolivas suite a sa maladie.
1- Con est tombé malade suite au stress et travail imposé par la LKML sur son scheduler. En gros il propose un patch et au lieu d'y contribuer tout le monde l'a fusillé en lui disant que l'idée est bonne, mais l'implémentation n'est pas ce qu'ils attendaient.
2 - Ingo a validé le concept mais a lui aussi refusé l'implementation de Con. Il disparait et reapparait avec son CFS.
> 4- La lecture de la liste de diffusion du noyau montre que Con a commis quelques erreurs: des accusations paranoïaques et de tricherie contre CFS (e.g. l'histoire du renice de X).
Le renice de X est une vérité vraie. Je 'tinvite a relire la LKML il y a quelques années ou Ingo et Linus defendaient le fait que renicer X c'etait pas la bonne approche dans la course a l'interactivité.
Il est donc compréhensible que Con trouve que le renice automatique de X dans les premieres version de CFS soit de la pure triche pour pallier au manque d'interactivité de CFS dans sa jeunesse.
> De son coté, Ingo Molnar a toujours rendu à César ce qui lui appartient. Il a clairement déclaré que certains concepts venaient de Kolivas, et n'a jamais dans ses changelogs, prétendu que son poulain était le meilleur.
Oui et non, il est comprehensible que Con qui bosse depuis plusieurs années sur l'amelioration du scheduler ait les boules.
Il s'est fait refuser le staircase scheduler, bien qu'il eut:
- été plus simple que le scheduler mainline
- intégré la notion d'interactivité de facon naturelle et deterministe.
Il s'est fait refuser RSDL (Rotating Staircase Deadline Scheduler) et SD:
- car l'approche etait un peu hors norme
- car personne ne l'a vraiment concretement aidé à l'ameliorer en respectant le design de base (y a eu des patchs envoyes pour integrer des heuristiques de bonus d'interactivité par celui qui tune ce meme parametre dans le noyau mainline depuis quelque temps). Mais le fameux 'envoies ton patch au lieu de critiquer gratuitement' a pas eu lieu. Les critiques etaient là, les patchs non.
On peu donc comprendre que l'arrivée de CFS soit mal percue. Ingo n'a pas patché SD, il s'est mis a coder dans son coin en repompant l'idee de base, fait un truc a sa sauce, et attiré les developpeurs interesses car il est plus affluant dans la communauté LKML.
> 5- Quand des défauts, bugs ou problèmes plus conceptuels ont été abordés pour les deux projets, Ingo Molnar a comme d'habitude corrigé les bugs (dans les heures qui suivaient). Cela fait de nombreuses version de CFS où il n' y a pas de bugs (il y a une constante: des gens rapportent des bugs, et réalisent ensuite qu'il se sont trompés où que le bug est en fait présent sous le noyau de base ou du à autre chose (e.g. le cas d' un bug de XTerm la semaine dernière)). Les problèmes soulevées par Bill Davidsen contre SD n'ont jamais reçu de réponse, ce qui a poussé Linus a faire un rappel à l'ordre.
48 versions de SD, c'est peut etre pas assez ?
En fait, tu disais que le post original de la thread etait biaisé en faveur de Con, et bien j'ose dire que le tien est clairement biaisé en faveur d'Ingo.
L'erreur c'est que tu as uniquement suivi la LKML pour te faire une idee, et SD a été développé sur la mailing list de Con Kolivas. Cela explique certainement ta partialité.
Mais ayant vu les choses sur les deux MLs, je dirais que Ingo a fait un petit coup de pute a Con:
- il ne l'aide pas
- il deprecie le design
- il vient avec un concurrent
- il attire a lui tous ceux qui seraient en mesure d'aider Con
- il renie certaines choses qu'il a rejeté des années durant pour son scheduler O(1) mainline (modularité, pas de bonus d'interactivité ...).
Donc oui, Con a eu les boules, c'est normal.
Ingo a mergé son CFS, tant mieux pour Linux qui profitera d'un scheduler techniquement supérieur au mainline 2.5.x->2.6.21.
PS: malgré mon plaidoyer pour Con, je trouve qu'Ingo fait du super boulot. C'est juste la facon de faire qui a été "border line" et que j'ai trouvé un peu irrespectueuse humainement.
Par contre, ce qui peut être fait, c'est de coder une glue C->C++ sur laquelle se baserait le plugin. Dans ce cas, le projet Gimp+plugin greycstoration serait 100% C, il aurait une chance d'etre revu et accepté. Par contre il faudrait, j'imagine, que cette glue C->C++ soit maintenue Upstream (David quoi :-)) sinon on se retrouve dans le cas où Gimp dépend de C++.
Un autre projet fait ce genre de chose. Il s'agit de libopenraw, Hugue Figuiere n'est pas pour un retour au C, il lui prefere le C++ pour ce projet. Par contre conscient que le C++ pose trop souvent des problemes d'ABI, il a codé une API C qui fait le pont entre le C++ et le C.
Cette réponse n'a rien de trollesque... si ton post visait à préciser que toutes ces fonctionnalitées étaient présentes dans GIT, il est vrai que j'aurais pu le mentionner dans la mesure où je suis l'évolution des deux projets sur leurs MLs respectives.
Donc je te reprend sur les quelques points pour apporter des précisions:
>StGit propose une gestion de queue de patch depuis longtemps
La gestion n'est pas totalement identique. Mais la palme de la gestion de patchs revient dans ce cas à Quilt de Andrew Morton dont StGit et Mq sont des copies fonctionnelles qui profitent des couches SCM fournies par Git et Mercurial.
>La gestion des mails est dans Git depuis le début (et a été améliorée il y a quelques mois)
Tout à fait vrai. Linus a toujours aimé avoir des outils de gestion de patchs au format mbox (format historique des emails sous unix). Il est donc tout à fait normal qu'il l'ait implémenté dès le départ dans GIT...
>Bisect provient directement de Git, c'est une belle et vraie invention de Linus
Cette fonctionnalité vise surtout à formaliser par du code une pratique très couramment utilisée par tous ceux qui recherchent les bugs dans le noyau. L'algorithme est une simple dichotomie sur l'intervalle de revisions identifié comme celui qui introduit le bug.
>Moi ce qui me gêne le plus, c'est la taille de la communauté Mercurial, qui se développe moins vite que Git (la communauté autant que Mercurial).
Bah oui, mais Mercurial n'a pas eu de Linus Torvalds à sa tête. Et pour un projet, un grand nom comme Linus Torvalds, ça donne envie de s'y pencher... Surtout vu comme GIT a été présenté lors de son officialisation: "GIT remplaçant de BitKeeper pour la gestion des sources de noyau". Il est toujours plus agréable d'associer ses contributions à des projets de renom.
<malife et avis perso>
Moi ce qui m'avait attiré vers Mercurial, c'était la démarche constructive de Matt Mackal, qui essayait de montrer à Linus ses erreurs. Linus refusait d'écouter les arguments avancés. Linus a monopolisé les forces de dev autour d'un projet qui techniquement ressemble plus à un hack qu'à un vrai programme pensé et construit dans les règles de l'art. Ce n'est pas une critique gratuite et trollesque, mais GIT, c'est écris en C pour le coeur, perl, python et Posix Sh pour les porcelains... ca utilisait historiquement rsync qui a mis a genoux kernel.org, puis est passé à un daemon plus malin pour distribuer les changesets manquants entre repositories... le backend fichier tend a espacer dans des répertoires différents des sources qui sont proches lors d'un checkout (dû à l'adressage par hash)... puis remarquant l'inneficacité de la bête lorsque le dictionnaire possède trop d'entrées dans l'index, Linus a eu recours à des packs d'entrées qu'on doit prendre soin de bien maintenir. Ca me fait penser a une idee qui germait dans arch/tla depuis pas mal de temps qui consitait à grouper plusieurs changesets ensembles pour eviter le trashing d'inodes et le parcours inutile du filesystem lors des update et des synchro réseau...
Bref pour moi GIT a le succès qu'on lui connais car il a été démarré par Linus Torvalds... s'il avait été publié par un illustre inconnu, il n'aurait pas tenu la comparaison en terme de fonctionnel avec Monotone, Arch/tla, bazaar 1.x, ou même Darcs, Il n'avait pour lui que sa rapidité à trouver les fichiers changés (man stat(2)).
Matt Mackal a su réfléchir et concevoir quelque chose qui tout en proposant les mêmes fonctionnalités, avait une belle architecture, homogène, lisse. Et même si ce n'est pas codé en C oil of codaz (dédicace GCU Squad), Mercurial est ultra véloce même si Python n'est pas reconnu pour sa rapidité d'excution dans certains cas
</malife et avis perso>
Donc au final on est globalement d'accord, mais nos points de vue diffèrent car nous sommes fan de deux projets concurrents :-) Que le meilleur gagne !
Je voulais profiter de cette news sur GIT pour parler de son cousin Mercurial. Pour ceux qui ne connaissent pas, Mercurial est né suite à la publication un peu hative de GIT par Linus Torvalds. Matt Mackal trouvait que GIT utilisait des raccourcis techniques un peu gros et décida de coder un prototype de SCM en python pour tenter de faire quelque chose de plus propre. Voilà coté historique. Dans la pratique les deux s'utilisent globalement de la même façon. Mercurial possède un meilleur support windows que son homologue.
Donc Mercurial 0.8.1 est sorti il y a de çà 2 semaines en apportant un lot assez important de fonctionnalités.
Nouvelles extensions:
- mq: gestion de queue de patchs. S'inspire du workflow d'un quilt, mais on garde les avantages d'avoir ses sources sous contrôle d'un SCM
- mail: où l'art d'envoyer ses changements via email sans se soucier de rien.
- gpg: permet de signer chaque changeset pour les gens qui commit, et de façon symmétrique, de vérifier les signatures pour ceux qui pull les changesets.
- hgbisect: extension qui aide a retrouver le changeset coupable d'un bug identifié sur un intervalle de révisions donné.
Nouvelles fonctionnalités:
- La sortie de plusieurs commandes (dont 'log') peut être patronnée (templatée), de la même façon que les pages web de la commande serve. On peut donc par exemple générer des ChangeLog dans un format propre à son projet.
- Possibilité d'utiliser la commande 'incoming' sur des repositories distants et ainsi savoir quels changements seraient rapatriés en local.
...
Bugfix:
- Quelques bugs sous windows, principalement des différences de comportement de python sous les environnements Unix et Windows.
- ... hg log pour les courageux :-)
Et le développement continue... la future version intègre déjà un nouveau format de repository qui peut alléger leur taille jusqu'à 40%, en utilisant deux fois moins d'inodes... ce changement a pour effet de minimiser la mémoire requise à pas mal d'endroits, d'accélerer certaines commandes... bref que du bon. Une commande 'archive' est arrivée pour faire des export des sources très simplement en zip, targz, tarbz2...
Enfin je veux pas trop vampiriser la news sur GIT pour promouvoir Mercurial, mais que tous ceux qui souhaitent utiliser GIT, testent aussi Mercurial. Mercurial est souvent plus "propre" que GIT, de plus il est portable... user friendly et son poil brille plus fort que celui de GIT :-)
Les mutex et semaphores noyaux ne sont pas directement exposés en userspace.
Pour info, les mutex que tu utilises dans la libpthread NPTL (glibc 2.3 sur noyau 2.6) utilisent les futex noyaux... Allez encore un terme pour embrouiller son monde :-)
Voir http://en.wikipedia.org/wiki/Futex
Ed_ou_ard, je ne suis pas d'origine anglo-saxone, donc pas de w.
>j'ai voulu développer un nouveau pilote Ethernet sous Linux, je veut savoir l'emplacement exacte du pilote de ma carte reseau,
Ca se trouve dans le code source du noyau linux. Plutot dans linux/drivers/net
>et je veut savoir est ce que il existe un seul pilote pour toutes les cartes réseau, ou chaque carte a son pilote.
Non il n'y a pas un seul pilote pour toutes les cartes ethernet. Il existe une couche commune de gestion du protocole TCP/UDP/IP/ARP (voir linux/net) etc... mais pour la gestion de chaque matériel un driver unique existe pour chaque type de puce sous jacente.
>j'utilise linux RedHat 9 noyau 2.4.20-8.
Je ne comprend toujours pas ce que tu souhaites vraiment. Si développer un driver est ton but, alors il ne te reste plus qu'a bouquiner le ebook que je t'avais indiqué dans tes questions forum précédentes et lire les sources de drivers existant pour t'en inspirer.
Si utiliser une carte ethernet sous ta redhat 9 est ton objectif, alors là je te conseille tout simplement de mettre a jour, si possible, avec une distrib qui supporte ta carte. Tu n'as pas besoin de "développer" dans ce cas.
Vu tes questions dans tes posts précédents, je penche plutot pour la seconde option, et je te conseille donc dans l'avenir de mieux formuler tes questions sous peine de ne jamais avoir une réponse adaptée à tes besoins.
>Oui, mais à condition d'utiliser un package source Debian.
Non, tout noyau est bon pour kernel-package. C'est meme la facon conseillée d'installer un noyau kernel.org sur une debian.
Le seul truc auquel il fallait faire gaffe avant etait d'inclure les patchs qui allaient bien pour pouvoir lire un initrd cramfs. Mais il y avait des solutions qui consitaient a se passer de cramfs en configurant quelques variables les fichiers de config et donc de ne pas patcher ton noyau du tout. C'est ainsi que j'ai utilisé des initrd romfs+gzip pendant 2 ans.
Mais maintenant, comme les 2.6 utilisent de preference des initramfs au format cpio, plus besoin de se prendre la tete, un noyau kernel.org boote tel quel compilé par make-kpkg, couplé au initramfstools ou a yaird.
Attention toutefois a toujours activer en dur le support ramdisks+initrd.
l'extension MQ qui permet d'avoir la puissance de Mercurial et la possibilité de gérer des patchs à la Quilt d'Andrew Morton. Pour ceux qui ne connaissent pas, il s'agit de maintenir des patchs a appliquer sur un source public. L'exemple le plus connu est le source des noyaux d'Andrew Morton qui maintient pres de 1000 patchs grâce à Quilt en parallele des sources de Linus Torvalds.
Et pour ceux qui se demanderaient pourquoi Andrew Morton n'utilise pas GIT, la réponse est toute simple:
Linus Torvalds travaille sur le merge final, il s'agit pour lui d'appliquer des patchs une seule fois. Andrew Morton doit pouvoir maintenir des patchs de facon indépendante pour les soumettre a linus apres une prériode de maturation plus ou moins longue...
Voir http://kerneltrap.org/node/6059 pour plus de détails.
Attention la il s'agit plutot de gros projets... avec plein de merge dans tous les sens.
Des projets completement lineaires pour se faire la main (desole je n'ai pas d'hebergeur python, donc je met un tar a disposition): http://ed.gomez.free.fr/mercurial/
Je trouve très flatteur que tu me mettes dans le même panier que Fabrice Bellard, car il est d'un tout autre calibre (supérieur) que moi.
Attend je relis la liste de ses projets... ah oui pas de doute, tinygl, qemu, tinycc, ffmpeg, qemacs... Fabrice Bellard doit vivre dans un monde où les journées n'ont pas la même durée que dans le notre. Mais comment fait il pour être si actif ?! :-)
>la scène warez sans qui je ne serais pas si connu. Leur généreuse adoption m'a grandement popularisé...
Merci pour l'insulte, en tant que mainteneur d'XviD pendant plusieurs annéees c'est clair que ma motivation première était de devenir un illustre inconnu visant à alimenter la scène warez. Non sérieusement, t'y crois deux minutes à ton commentaire ?
Je pense plus simplement qu'XviD est utilisé parce qu'il satisfait plus les gens qui alimentent les réseaux warez. Peut être trouvent ils que les films sont pour une taille donnée de meilleure qualité... non ca doit etre un argument trop rationnel...
>Peut être que ces options d'XviD sont hors norme justement.
Faux, ce sont les platines qui sont hors normes... aujourd'hui aucune platine ne supporte completement la norme MPEG4 ASP.
Donc si tes platines ne savent pas lire tous les XviD, qui je le rappelle n'est qu'une implementation de la norme ISO MPEG4 ASP, c'est la faute à ceux qui te vendent n'importe quoi sous des appellations erronées.
>Qu'est-ce qui l'empêche d'installer une distrib 64 bits à la place ou à coté de son Windows ? Ou alors il est Redmondophile fanatique ?
Non, juste une question d'habitude...
lui son dada c'est le codage vidéo, il ne souhaite pas migrer car il aime bien son environnnement windows. Je ne vois aucun mal à ce qu'il continue à travailler sous windows sans pour autant le qualifier de "redmondophile fanatique".
je salue la sortie de cette version qui aura bien tardée. C'est avec plaisir que je vois le développement de ce codec reprendre à la suite de mon départ du "poste" de mainteneur.
sysKin, l'autre développeur actif à l'époque où j'étais encore mainteneur, semble reprendre gout au hacking d'XviD, et je pense que les possesseurs d'architecures bicore AMD64 seront les grands bénéficiaires de ses efforts de développement:
- Multithreading et amélioration de la qualité par ajout de nouveaux algos autrefois peu accessibles car trop gourmands pour les configs utilisateurs.
Seul bémol, il possède un bicore 4200+ tournant sous windows 32bit, ce qui me fait craindre, que les adorateurs du full 64bit ne pourront peut etre pas profiter de tout sans faire appel a la compat 32bit. Enfin, moindre mal car xvid ne depend que de la libc, et donc je suis quasi sûr qu'aucune chroot ne sera pas nécessaire.
Enfin, voilà bonne chance à sysKin, XviD le mérite bien.
Le projet plugsched formalise l'interface noyau<->scheduler pour linux et permet ainsi l'integration de divers scheduler au sein d'un meme noyau: ingo, staircase, zaphod...
Il vaut mieux que tu debutes alors par apprendre les bases du langage C++. Ca te permettra par la suite de beaucoup mieux comprendre ce que tu fais dans une appli QT.
Dans l'ordre:
- syntaxe (if, else, do, while, new, delete, pointeur, reference, modele d'exception etc...)
- facon de concevoir l'objet en C++ (class/struct, heritages, templates etc...)
- entrees/sorties
Apres un passage par la STL (Standard Template Library) qui te donne un bon ensemble d'outils rudimentaires mais extremement utiles, tu pourras commencer à t'interesser à l'exploitation de librarires C++ de haut niveau telles que QT,
Pour faire un paralelle avec la langue francaise, avant d'ecrire des dissertations en Francais, tu as appris a parler francais. C'est pareil pour le C++, si tu ne connais pas le langage lui même, tu éprouveras beaucoup de difficultes à écrire des programmes C++, car les bases te manqueront.
>N'étant pas spécialiste du domaine, je veux bien te croire. Mais ma question est donc : pourquoi alors Fluendo prend la peine de contribuer et d'utiliser Theora, disant ne pas pouvoir prendre le risque d'utiliser Xvid ?
Comme ca a été dit avant, XviD etant une implementation d'MPEG4, on doit bien violer quelques brevets au passage de façon certaine. Or derriere toute norme MPEG, un consortium d'ayant droit gere les droits liees a l'exploitation des normes de facon centralisée: le MPEG-LA http://www.mpegla.com/index1.cfm(...)
Dans le cas de Theora, tu as une boite On2, qui a promis a Xiph que son portefeuille de brevets relatifs à VP3 (base de theora) ne sera jamais exploité. Mais rien ne dit que On2 couvre avec ses brevets "gentils" l'ensemble des techniques mathematiques employees dans VP3/Theora.
Donc d'un coté, tu as une techno dont tu sais que:
- elle est minée par des brevets
- ces brevets sont gérés de facon centralisée par un consortium qui redistribue les royalties aux ayant droit.
De l'autre coté, tu as une techno dont tu sais que:
- Elle contient des procedes brevetes, dont certains ne posent pas probleme car on sait qu'ils ne seront jamais exploité par On2, et "surement" d'autres brevets dont on ne sait rien.
- On2 gere ses brevets, pour les autres brevets... c'est le néant, c'est à chaque entreprise détentrice de faire valoir ses droits.
Donc entre une techno clairement hostile (brevets connus+gestion centralisée et hyper organisée de leur exploitation) et une techno un poil friendly (majeur partie des brevets connus et innofensifs)... bah tu choisis de supporter la seconde, c'est clairement moins risqué et en plus c'est clairement plus en adéquation avec les licenses utilisées dans les projets formant la base de fluendo (gstreamer entre autres).
Ils ont su rester pragmatique et realiste. Ils ne pouvaient se mettre en cas d'infraction délibérée puisqu'il s'agit d'une entreprise légalement déclarée en Espagne il me semble.
# Rawstudio
Posté par Edouard Gomez (site web personnel) . En réponse à la dépêche Linux et la photographie : état des lieux. Évalué à 3.
rawstudio
Libre, basé sur dcraw pour la partie decodage du raw, le reste de la chaine de traitement est faite maison, optimisée MMX/SSE/3DNow! pour Intel/AMD 32/64bit.
Voir: http://rawstudio.org/
# Je code donc je suis
Posté par Edouard Gomez (site web personnel) . En réponse au journal Et vous, avez-vous déjà participé à un LL?. Évalué à 4.
2001 - 2005: XviD
2004 - 2005: Frontend Transcode/Mplayer pour XviD
2005 - De nos jours: Petites contributions/bugfix sur divers logiciels (ffmpeg, mercurial, rawstudio, enblend...)
Mes motivations:
Rien de particulier juste l'envie de le faire quand j'ai du temps à y consacrer.
# libc
Posté par Edouard Gomez (site web personnel) . En réponse au journal Le meilleur éditeur de texte ? [FEU A VOLONTE]. Évalué à 10.
read(2)
close(2)
Avec ca, tu fais tout ce que font les autres editeurs. Pourquoi utiliser du bloatware quand la libc te fournit le strict necessaire ?
[^] # Re: Fin de la branche CK
Posté par Edouard Gomez (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 2.6.22. Évalué à 9.
> 1- Il est jugé techniquement supérieur
Son design fait intervenir des structures plus complexes a manipuler que le Staircase Deadline (SD). Si bien qu'il ajoute des lignes de code a sched.c là ou SD en enleve et le rend plus simple a maintenir.
> 2- Ingo Molnar est capable de travailler en équipe et d'accepter les contributions d'autres personnes à "son bébé". Il suffit de regarder les changelogs de CFS pour voir que de nombreuses améliorations ne sont pas de lui. Dans un projet aussi communautaire que linux, c'est fondamental (cf. la situation de la couche IDE des noyaux 2.0, 2.2).
Ingo est un vieux routard du noyau, il a une aura dans la communauté LKML qui attire beaucoup plus qu'un pauvre gars, même pas informaticien qui tente de convaincre son monde depuis bientot 5 ans au travers de patchs toujours refusés upstream faute de consensus/perseverence.
> 3- Ingo Molnar lance un projet et le maintient ou bien lui trouve un autre mainteneur (le dernier noyau realtime a été annoncé par Thomas Gleixner qui à l'origine était un petit contributeur, et maintenant est le principal contributeur de ce patch). Quelques temps après avoir créé SD, Kolivas a du s'arrêter de développer pour des raisons de santé. C'est ce qui a poussé Ingo Molnar à lancer CFS. Il n' y avait personne qui pouvait/voulait continuer le travail de Con Kolivas. C'est important d'avoir l'assurance que tel ou tel projet sera maintenu.
Faux, CFS n'est pas du au retrait de Con Kolivas suite a sa maladie.
1- Con est tombé malade suite au stress et travail imposé par la LKML sur son scheduler. En gros il propose un patch et au lieu d'y contribuer tout le monde l'a fusillé en lui disant que l'idée est bonne, mais l'implémentation n'est pas ce qu'ils attendaient.
2 - Ingo a validé le concept mais a lui aussi refusé l'implementation de Con. Il disparait et reapparait avec son CFS.
> 4- La lecture de la liste de diffusion du noyau montre que Con a commis quelques erreurs: des accusations paranoïaques et de tricherie contre CFS (e.g. l'histoire du renice de X).
Le renice de X est une vérité vraie. Je 'tinvite a relire la LKML il y a quelques années ou Ingo et Linus defendaient le fait que renicer X c'etait pas la bonne approche dans la course a l'interactivité.
Il est donc compréhensible que Con trouve que le renice automatique de X dans les premieres version de CFS soit de la pure triche pour pallier au manque d'interactivité de CFS dans sa jeunesse.
> De son coté, Ingo Molnar a toujours rendu à César ce qui lui appartient. Il a clairement déclaré que certains concepts venaient de Kolivas, et n'a jamais dans ses changelogs, prétendu que son poulain était le meilleur.
Oui et non, il est comprehensible que Con qui bosse depuis plusieurs années sur l'amelioration du scheduler ait les boules.
Il s'est fait refuser le staircase scheduler, bien qu'il eut:
- été plus simple que le scheduler mainline
- intégré la notion d'interactivité de facon naturelle et deterministe.
Il s'est fait refuser RSDL (Rotating Staircase Deadline Scheduler) et SD:
- car l'approche etait un peu hors norme
- car personne ne l'a vraiment concretement aidé à l'ameliorer en respectant le design de base (y a eu des patchs envoyes pour integrer des heuristiques de bonus d'interactivité par celui qui tune ce meme parametre dans le noyau mainline depuis quelque temps). Mais le fameux 'envoies ton patch au lieu de critiquer gratuitement' a pas eu lieu. Les critiques etaient là, les patchs non.
On peu donc comprendre que l'arrivée de CFS soit mal percue. Ingo n'a pas patché SD, il s'est mis a coder dans son coin en repompant l'idee de base, fait un truc a sa sauce, et attiré les developpeurs interesses car il est plus affluant dans la communauté LKML.
> 5- Quand des défauts, bugs ou problèmes plus conceptuels ont été abordés pour les deux projets, Ingo Molnar a comme d'habitude corrigé les bugs (dans les heures qui suivaient). Cela fait de nombreuses version de CFS où il n' y a pas de bugs (il y a une constante: des gens rapportent des bugs, et réalisent ensuite qu'il se sont trompés où que le bug est en fait présent sous le noyau de base ou du à autre chose (e.g. le cas d' un bug de XTerm la semaine dernière)). Les problèmes soulevées par Bill Davidsen contre SD n'ont jamais reçu de réponse, ce qui a poussé Linus a faire un rappel à l'ordre.
48 versions de SD, c'est peut etre pas assez ?
En fait, tu disais que le post original de la thread etait biaisé en faveur de Con, et bien j'ose dire que le tien est clairement biaisé en faveur d'Ingo.
L'erreur c'est que tu as uniquement suivi la LKML pour te faire une idee, et SD a été développé sur la mailing list de Con Kolivas. Cela explique certainement ta partialité.
Mais ayant vu les choses sur les deux MLs, je dirais que Ingo a fait un petit coup de pute a Con:
- il ne l'aide pas
- il deprecie le design
- il vient avec un concurrent
- il attire a lui tous ceux qui seraient en mesure d'aider Con
- il renie certaines choses qu'il a rejeté des années durant pour son scheduler O(1) mainline (modularité, pas de bonus d'interactivité ...).
Donc oui, Con a eu les boules, c'est normal.
Ingo a mergé son CFS, tant mieux pour Linux qui profitera d'un scheduler techniquement supérieur au mainline 2.5.x->2.6.21.
PS: malgré mon plaidoyer pour Con, je trouve qu'Ingo fait du super boulot. C'est juste la facon de faire qui a été "border line" et que j'ai trouvé un peu irrespectueuse humainement.
[^] # Re: S'adresser aux devs de GIMP ?
Posté par Edouard Gomez (site web personnel) . En réponse au journal GREYCstoration : Appel à contribution. Évalué à 2.
Par contre, ce qui peut être fait, c'est de coder une glue C->C++ sur laquelle se baserait le plugin. Dans ce cas, le projet Gimp+plugin greycstoration serait 100% C, il aurait une chance d'etre revu et accepté. Par contre il faudrait, j'imagine, que cette glue C->C++ soit maintenue Upstream (David quoi :-)) sinon on se retrouve dans le cas où Gimp dépend de C++.
Un autre projet fait ce genre de chose. Il s'agit de libopenraw, Hugue Figuiere n'est pas pour un retour au C, il lui prefere le C++ pour ce projet. Par contre conscient que le C++ pose trop souvent des problemes d'ABI, il a codé une API C qui fait le pont entre le C++ et le C.
# Petite correction
Posté par Edouard Gomez (site web personnel) . En réponse au journal Droit de réponse. Évalué à 1.
> Quand je vous disais que l'argument de la voiture sans roue aller arriver ...
Quand je vous disais que l'argument de la voiture sans roue all*ait* arriver ...
[^] # Re: Mercurial, le fils caché de GIT grandit lui aussi
Posté par Edouard Gomez (site web personnel) . En réponse à la dépêche Sortie de Git 1.3.0. Évalué à 5.
Donc je te reprend sur les quelques points pour apporter des précisions:
>StGit propose une gestion de queue de patch depuis longtemps
La gestion n'est pas totalement identique. Mais la palme de la gestion de patchs revient dans ce cas à Quilt de Andrew Morton dont StGit et Mq sont des copies fonctionnelles qui profitent des couches SCM fournies par Git et Mercurial.
>La gestion des mails est dans Git depuis le début (et a été améliorée il y a quelques mois)
Tout à fait vrai. Linus a toujours aimé avoir des outils de gestion de patchs au format mbox (format historique des emails sous unix). Il est donc tout à fait normal qu'il l'ait implémenté dès le départ dans GIT...
>Bisect provient directement de Git, c'est une belle et vraie invention de Linus
Cette fonctionnalité vise surtout à formaliser par du code une pratique très couramment utilisée par tous ceux qui recherchent les bugs dans le noyau. L'algorithme est une simple dichotomie sur l'intervalle de revisions identifié comme celui qui introduit le bug.
>Moi ce qui me gêne le plus, c'est la taille de la communauté Mercurial, qui se développe moins vite que Git (la communauté autant que Mercurial).
Bah oui, mais Mercurial n'a pas eu de Linus Torvalds à sa tête. Et pour un projet, un grand nom comme Linus Torvalds, ça donne envie de s'y pencher... Surtout vu comme GIT a été présenté lors de son officialisation: "GIT remplaçant de BitKeeper pour la gestion des sources de noyau". Il est toujours plus agréable d'associer ses contributions à des projets de renom.
<malife et avis perso>
Moi ce qui m'avait attiré vers Mercurial, c'était la démarche constructive de Matt Mackal, qui essayait de montrer à Linus ses erreurs. Linus refusait d'écouter les arguments avancés. Linus a monopolisé les forces de dev autour d'un projet qui techniquement ressemble plus à un hack qu'à un vrai programme pensé et construit dans les règles de l'art. Ce n'est pas une critique gratuite et trollesque, mais GIT, c'est écris en C pour le coeur, perl, python et Posix Sh pour les porcelains... ca utilisait historiquement rsync qui a mis a genoux kernel.org, puis est passé à un daemon plus malin pour distribuer les changesets manquants entre repositories... le backend fichier tend a espacer dans des répertoires différents des sources qui sont proches lors d'un checkout (dû à l'adressage par hash)... puis remarquant l'inneficacité de la bête lorsque le dictionnaire possède trop d'entrées dans l'index, Linus a eu recours à des packs d'entrées qu'on doit prendre soin de bien maintenir. Ca me fait penser a une idee qui germait dans arch/tla depuis pas mal de temps qui consitait à grouper plusieurs changesets ensembles pour eviter le trashing d'inodes et le parcours inutile du filesystem lors des update et des synchro réseau...
Bref pour moi GIT a le succès qu'on lui connais car il a été démarré par Linus Torvalds... s'il avait été publié par un illustre inconnu, il n'aurait pas tenu la comparaison en terme de fonctionnel avec Monotone, Arch/tla, bazaar 1.x, ou même Darcs, Il n'avait pour lui que sa rapidité à trouver les fichiers changés (man stat(2)).
Matt Mackal a su réfléchir et concevoir quelque chose qui tout en proposant les mêmes fonctionnalités, avait une belle architecture, homogène, lisse. Et même si ce n'est pas codé en C oil of codaz (dédicace GCU Squad), Mercurial est ultra véloce même si Python n'est pas reconnu pour sa rapidité d'excution dans certains cas
</malife et avis perso>
Donc au final on est globalement d'accord, mais nos points de vue diffèrent car nous sommes fan de deux projets concurrents :-) Que le meilleur gagne !
# Mercurial, le fils caché de GIT grandit lui aussi
Posté par Edouard Gomez (site web personnel) . En réponse à la dépêche Sortie de Git 1.3.0. Évalué à 9.
Je voulais profiter de cette news sur GIT pour parler de son cousin Mercurial. Pour ceux qui ne connaissent pas, Mercurial est né suite à la publication un peu hative de GIT par Linus Torvalds. Matt Mackal trouvait que GIT utilisait des raccourcis techniques un peu gros et décida de coder un prototype de SCM en python pour tenter de faire quelque chose de plus propre. Voilà coté historique. Dans la pratique les deux s'utilisent globalement de la même façon. Mercurial possède un meilleur support windows que son homologue.
Donc Mercurial 0.8.1 est sorti il y a de çà 2 semaines en apportant un lot assez important de fonctionnalités.
Nouvelles extensions:
- mq: gestion de queue de patchs. S'inspire du workflow d'un quilt, mais on garde les avantages d'avoir ses sources sous contrôle d'un SCM
- mail: où l'art d'envoyer ses changements via email sans se soucier de rien.
- gpg: permet de signer chaque changeset pour les gens qui commit, et de façon symmétrique, de vérifier les signatures pour ceux qui pull les changesets.
- hgbisect: extension qui aide a retrouver le changeset coupable d'un bug identifié sur un intervalle de révisions donné.
Nouvelles fonctionnalités:
- La sortie de plusieurs commandes (dont 'log') peut être patronnée (templatée), de la même façon que les pages web de la commande serve. On peut donc par exemple générer des ChangeLog dans un format propre à son projet.
- Possibilité d'utiliser la commande 'incoming' sur des repositories distants et ainsi savoir quels changements seraient rapatriés en local.
...
Bugfix:
- Quelques bugs sous windows, principalement des différences de comportement de python sous les environnements Unix et Windows.
- ... hg log pour les courageux :-)
Et le développement continue... la future version intègre déjà un nouveau format de repository qui peut alléger leur taille jusqu'à 40%, en utilisant deux fois moins d'inodes... ce changement a pour effet de minimiser la mémoire requise à pas mal d'endroits, d'accélerer certaines commandes... bref que du bon. Une commande 'archive' est arrivée pour faire des export des sources très simplement en zip, targz, tarbz2...
Enfin je veux pas trop vampiriser la news sur GIT pour promouvoir Mercurial, mais que tous ceux qui souhaitent utiliser GIT, testent aussi Mercurial. Mercurial est souvent plus "propre" que GIT, de plus il est portable... user friendly et son poil brille plus fort que celui de GIT :-)
[^] # Re: mutex
Posté par Edouard Gomez (site web personnel) . En réponse à la dépêche Linux 2.6.16 est sorti. Évalué à 9.
Pour info, les mutex que tu utilises dans la libpthread NPTL (glibc 2.3 sur noyau 2.6) utilisent les futex noyaux... Allez encore un terme pour embrouiller son monde :-)
Voir http://en.wikipedia.org/wiki/Futex
# ...
Posté par Edouard Gomez (site web personnel) . En réponse au message pilote réseau for linux 2.4.20-8. Évalué à 3.
Ed_ou_ard, je ne suis pas d'origine anglo-saxone, donc pas de w.
>j'ai voulu développer un nouveau pilote Ethernet sous Linux, je veut savoir l'emplacement exacte du pilote de ma carte reseau,
Ca se trouve dans le code source du noyau linux. Plutot dans linux/drivers/net
>et je veut savoir est ce que il existe un seul pilote pour toutes les cartes réseau, ou chaque carte a son pilote.
Non il n'y a pas un seul pilote pour toutes les cartes ethernet. Il existe une couche commune de gestion du protocole TCP/UDP/IP/ARP (voir linux/net) etc... mais pour la gestion de chaque matériel un driver unique existe pour chaque type de puce sous jacente.
>j'utilise linux RedHat 9 noyau 2.4.20-8.
Je ne comprend toujours pas ce que tu souhaites vraiment. Si développer un driver est ton but, alors il ne te reste plus qu'a bouquiner le ebook que je t'avais indiqué dans tes questions forum précédentes et lire les sources de drivers existant pour t'en inspirer.
Si utiliser une carte ethernet sous ta redhat 9 est ton objectif, alors là je te conseille tout simplement de mettre a jour, si possible, avec une distrib qui supporte ta carte. Tu n'as pas besoin de "développer" dans ce cas.
Vu tes questions dans tes posts précédents, je penche plutot pour la seconde option, et je te conseille donc dans l'avenir de mieux formuler tes questions sous peine de ne jamais avoir une réponse adaptée à tes besoins.
Bonne chance
[^] # Re: methode
Posté par Edouard Gomez (site web personnel) . En réponse au message Ou télécharger un kernel ?. Évalué à 1.
Non, tout noyau est bon pour kernel-package. C'est meme la facon conseillée d'installer un noyau kernel.org sur une debian.
Le seul truc auquel il fallait faire gaffe avant etait d'inclure les patchs qui allaient bien pour pouvoir lire un initrd cramfs. Mais il y avait des solutions qui consitaient a se passer de cramfs en configurant quelques variables les fichiers de config et donc de ne pas patcher ton noyau du tout. C'est ainsi que j'ai utilisé des initrd romfs+gzip pendant 2 ans.
Mais maintenant, comme les 2.6 utilisent de preference des initramfs au format cpio, plus besoin de se prendre la tete, un noyau kernel.org boote tel quel compilé par make-kpkg, couplé au initramfstools ou a yaird.
Attention toutefois a toujours activer en dur le support ramdisks+initrd.
# N'oublions pas...
Posté par Edouard Gomez (site web personnel) . En réponse au journal Sortie de Mercurial 0.8. Évalué à 5.
L'extension est dans un repository Mercurial:
http://hg.serpentine.com/mercurial/mq
Un mini howto explique comment l'installer/utiliser ici:
http://www.selenic.com/mercurial/wiki/index.cgi/MqExtension
Et pour ceux qui se demanderaient pourquoi Andrew Morton n'utilise pas GIT, la réponse est toute simple:
Linus Torvalds travaille sur le merge final, il s'agit pour lui d'appliquer des patchs une seule fois. Andrew Morton doit pouvoir maintenir des patchs de facon indépendante pour les soumettre a linus apres une prériode de maturation plus ou moins longue...
Voir http://kerneltrap.org/node/6059 pour plus de détails.
Pour les fans de GIT, il y a aussi StGit:
http://www.gelato.unsw.edu.au/archives/git/0511/11321.html
Un post intéressant le comparant à Hg+MQ (mail assez vieux vu l'evolution des deux SCM git et hg)
Aussi pour ceux qui voudraient tester Mercurial sans avoir de projet à se mettre sous la dent:
http://hg.serpentine.com/mercurial/mq
Attention la il s'agit plutot de gros projets... avec plein de merge dans tous les sens.
Des projets completement lineaires pour se faire la main (desole je n'ai pas d'hebergeur python, donc je met un tar a disposition):
http://ed.gomez.free.fr/mercurial/
Un outil pour passer d'un SCM a l'autre:
http://www.darcs.net/DarcsWiki/Tailor/
# Bon libre pour ce genre de chose
Posté par Edouard Gomez (site web personnel) . En réponse au message pilote Ethernet sous Linux. Évalué à 4.
http://www.oreilly.com/catalog/linuxdrive3/
Regarde la version gratuite electronique (lien OpenBook)
Ca couvre la totalité des choses a savoir pour developper des drivers pour les noyaux >=2.6.10.
[^] # Re: Des noms reviennent
Posté par Edouard Gomez (site web personnel) . En réponse à la dépêche Le codec vidéo libre XviD 1.1.0 est disponible. Évalué à 7.
Je trouve très flatteur que tu me mettes dans le même panier que Fabrice Bellard, car il est d'un tout autre calibre (supérieur) que moi.
Attend je relis la liste de ses projets... ah oui pas de doute, tinygl, qemu, tinycc, ffmpeg, qemacs... Fabrice Bellard doit vivre dans un monde où les journées n'ont pas la même durée que dans le notre. Mais comment fait il pour être si actif ?! :-)
[^] # Re: Je voudrais remercier
Posté par Edouard Gomez (site web personnel) . En réponse à la dépêche Le codec vidéo libre XviD 1.1.0 est disponible. Évalué à 10.
Merci pour l'insulte, en tant que mainteneur d'XviD pendant plusieurs annéees c'est clair que ma motivation première était de devenir un illustre inconnu visant à alimenter la scène warez. Non sérieusement, t'y crois deux minutes à ton commentaire ?
Je pense plus simplement qu'XviD est utilisé parce qu'il satisfait plus les gens qui alimentent les réseaux warez. Peut être trouvent ils que les films sont pour une taille donnée de meilleure qualité... non ca doit etre un argument trop rationnel...
>Peut être que ces options d'XviD sont hors norme justement.
Faux, ce sont les platines qui sont hors normes... aujourd'hui aucune platine ne supporte completement la norme MPEG4 ASP.
Donc si tes platines ne savent pas lire tous les XviD, qui je le rappelle n'est qu'une implementation de la norme ISO MPEG4 ASP, c'est la faute à ceux qui te vendent n'importe quoi sous des appellations erronées.
Bon vent ô trolleur insultant.
[^] # Re: Par la présente...
Posté par Edouard Gomez (site web personnel) . En réponse au journal XviD 1.1.0-final dans les bacs. Évalué à 4.
Non, juste une question d'habitude...
lui son dada c'est le codage vidéo, il ne souhaite pas migrer car il aime bien son environnnement windows. Je ne vois aucun mal à ce qu'il continue à travailler sous windows sans pour autant le qualifier de "redmondophile fanatique".
# Par la présente...
Posté par Edouard Gomez (site web personnel) . En réponse au journal XviD 1.1.0-final dans les bacs. Évalué à 6.
sysKin, l'autre développeur actif à l'époque où j'étais encore mainteneur, semble reprendre gout au hacking d'XviD, et je pense que les possesseurs d'architecures bicore AMD64 seront les grands bénéficiaires de ses efforts de développement:
- Multithreading et amélioration de la qualité par ajout de nouveaux algos autrefois peu accessibles car trop gourmands pour les configs utilisateurs.
Seul bémol, il possède un bicore 4200+ tournant sous windows 32bit, ce qui me fait craindre, que les adorateurs du full 64bit ne pourront peut etre pas profiter de tout sans faire appel a la compat 32bit. Enfin, moindre mal car xvid ne depend que de la libc, et donc je suis quasi sûr qu'aucune chroot ne sera pas nécessaire.
Enfin, voilà bonne chance à sysKin, XviD le mérite bien.
# Le noyau peut t'offrir ...
Posté par Edouard Gomez (site web personnel) . En réponse au message Cumul de X partitions sur un point de montage. Évalué à 3.
Sinon le 2.6.14 va integrer UnionFS qui permet de monter 2 partoches sur un meme point, par contre je ne sais pas ce qu'il permet exactement.
# Un projet permet d'integrer des schedulers plsu facilement
Posté par Edouard Gomez (site web personnel) . En réponse au message demmande d'aide "developpement d'un scheduler". Évalué à 1.
L'URL:
http://sourceforge.net/projects/cpuse/(...)
Par contre non ce n'est pas un module, ce n'est d'ailleurs pas possible, mais je n'ai pas trop le temps de m'etendre sur ce fait :-).
Bonne chance.
[^] # Re: l'UI ? quelle UI ?
Posté par Edouard Gomez (site web personnel) . En réponse au journal Tom Lord abandonne GNU Arch. Évalué à 1.
L'UI ligne de commande de arch/tla.
[^] # Re: Précisions ...
Posté par Edouard Gomez (site web personnel) . En réponse au journal Tom Lord abandonne GNU Arch. Évalué à 2.
J'avais pas osé.
[^] # Re: mercurial
Posté par Edouard Gomez (site web personnel) . En réponse au journal Tom Lord abandonne GNU Arch. Évalué à 2.
http://linuxfr.org/~GomGom/18736.html(...)
http://linuxfr.org/~GomGom/18881.html(...)
[^] # Re: api kde
Posté par Edouard Gomez (site web personnel) . En réponse au message Utilisation des fonctions API. Évalué à 3.
Il vaut mieux que tu debutes alors par apprendre les bases du langage C++. Ca te permettra par la suite de beaucoup mieux comprendre ce que tu fais dans une appli QT.
Dans l'ordre:
- syntaxe (if, else, do, while, new, delete, pointeur, reference, modele d'exception etc...)
- facon de concevoir l'objet en C++ (class/struct, heritages, templates etc...)
- entrees/sorties
Apres un passage par la STL (Standard Template Library) qui te donne un bon ensemble d'outils rudimentaires mais extremement utiles, tu pourras commencer à t'interesser à l'exploitation de librarires C++ de haut niveau telles que QT,
Pour faire un paralelle avec la langue francaise, avant d'ecrire des dissertations en Francais, tu as appris a parler francais. C'est pareil pour le C++, si tu ne connais pas le langage lui même, tu éprouveras beaucoup de difficultes à écrire des programmes C++, car les bases te manqueront.
Voila bonne chance.
[^] # Re: questions
Posté par Edouard Gomez (site web personnel) . En réponse au journal L'âge moyen d'une ligne de code d'XviD. Évalué à 2.
Comme ca a été dit avant, XviD etant une implementation d'MPEG4, on doit bien violer quelques brevets au passage de façon certaine. Or derriere toute norme MPEG, un consortium d'ayant droit gere les droits liees a l'exploitation des normes de facon centralisée: le MPEG-LA http://www.mpegla.com/index1.cfm(...)
Dans le cas de Theora, tu as une boite On2, qui a promis a Xiph que son portefeuille de brevets relatifs à VP3 (base de theora) ne sera jamais exploité. Mais rien ne dit que On2 couvre avec ses brevets "gentils" l'ensemble des techniques mathematiques employees dans VP3/Theora.
Donc d'un coté, tu as une techno dont tu sais que:
- elle est minée par des brevets
- ces brevets sont gérés de facon centralisée par un consortium qui redistribue les royalties aux ayant droit.
De l'autre coté, tu as une techno dont tu sais que:
- Elle contient des procedes brevetes, dont certains ne posent pas probleme car on sait qu'ils ne seront jamais exploité par On2, et "surement" d'autres brevets dont on ne sait rien.
- On2 gere ses brevets, pour les autres brevets... c'est le néant, c'est à chaque entreprise détentrice de faire valoir ses droits.
Donc entre une techno clairement hostile (brevets connus+gestion centralisée et hyper organisée de leur exploitation) et une techno un poil friendly (majeur partie des brevets connus et innofensifs)... bah tu choisis de supporter la seconde, c'est clairement moins risqué et en plus c'est clairement plus en adéquation avec les licenses utilisées dans les projets formant la base de fluendo (gstreamer entre autres).
Ils ont su rester pragmatique et realiste. Ils ne pouvaient se mettre en cas d'infraction délibérée puisqu'il s'agit d'une entreprise légalement déclarée en Espagne il me semble.
[^] # Re: questions
Posté par Edouard Gomez (site web personnel) . En réponse au journal L'âge moyen d'une ligne de code d'XviD. Évalué à 2.