Le modèle classique (deux versions concurrentes, une « stable » et une « de développement ») souffrait de quelques défauts, et depuis quelques temps un processus différent s'est installé. (NdM : il a été officialisé lors du dernier Kernel Developers Summit.)
Le nouveau modèle n'est en fait pas vraiment nouveau. Les patchs sont testés dans la série -mm maintenue par Andrew Morton, ce qui rappelle la branche -ac d'Alan Cox sur les noyaux 2.4. L'avantage est double : les nouveautés sont ajoutées plus rapidement à la série "stable", et les corrections de bogues peuvent être immédiatement appliqués à la série de développement.
NdM : la traditionnelle branche de développement (qui devrait être numérotée 2.7) n'apparaîtra quant à elle que bien plus tard, quand le besoin d'effectuer sur le noyau des modifications trop fondamentales pour la branche 2.6 se fera sentir. Ce qui est reproché au modèle « classique » :
- divergence trop importante entre la série « stable » et la série de développement, rendant le portage de code difficile entre les deux séries (changements dans l'API du noyau...) ;
- au bout d'un certain temps, la série stable devient obsolète ;
- les distribution fournissent des noyaux patchés, incluant des backports de fonctionnalités présentes dans la série de développement, ce qui peut poser des problèmes de compatibilités.
La branche d'Andrew Morton apporte une réelle nouveauté dans le processus de développement en traitant chaque patch de manière totalement indépendante, permettant ainsi de pouvoir les enlever à tout moment, ce qui n'était pas le cas dans les précédentes versions de développement.
Cela peut ressembler aux séries expérimentales d'Alan Cox, mais la série -mm effectue un suivi beaucoup plus poussé des patchs afin de garantir leur indépendance.
Le résultat est une série « stable » qui suit de plus près les évolutions de la version de développement. On peut citer notamment le passage de la taille de la pile du noyau de 8 à 4Ko, le support du bit NX (No eXecute) pour la protection des pages mémoires, ou encore le transfert de la fonctionnalité cryptoloop dans le device mapper.
Notez enfin qu'un article plus détaillé sur le sujet a été publié par Linux Weekly News. Il est pour l'instant accessible uniquement aux abonnés, les autres devant attendre une semaine avant de pouvoir le consulter.
Aller plus loin
- LWN : présentation du nouveau modèle lors du Kernel Summit (4 clics)
- Discussion sur la liste de discussion du noyau (2 clics)
- 1ère dépêche de KernelTrap (3 clics)
- 2ème dépêche de KernelTrap (3 clics)
# Erreur de casting
Posté par Philip Marlowe . Évalué à 1.
Alan Cox s'occupait du noyau 2.2. Pour le 2.4 c'est Marcelo Tosatti.
[^] # Re: Erreur de casting
Posté par Emmanuel Seyman . Évalué à 10.
La branche -ac a permis (permet toujours ?) de tester la nouvelle couche IDE du 2.6 . De mémoire, pour qu'un patch a la couche IDE soit accepté par Linux, il faut qu'il soit passé par AC.
# Question ?
Posté par skeespin (site web personnel) . Évalué à 8.
Il faudrais éviter, je penses les histoires comme:
"Mes drivers sont pour 2.6.7 et je suis en 2.6.4 !! Argh !!"
Enfin moi je suis resté sur du 2.4.x pour l'instant :p
[^] # Re: Question ?
Posté par Colin Leroy (site web personnel) . Évalué à 6.
J'imagine que tu parles de compatibilité des APIs (donc compatibilité à la compilation). Peut-être qu'elle n'y sera plus forcément.
Ce n'est pas forcément un mal, car de subtils changements au plus profond des APIs peut déjà "casser" un driver, mais à l'exécution plutôt qu'à la compilation. Cdc-acm, le driver de modem GPRS usb, m'a fait ce coup au 2.6.4 et 2.6.5.
Moins le problème est gros, plus il est difficile à trouver, donc une erreur à la compilation vaut mieux, pour moi, qu'un Oops sorti de nulle part...
Evidemment on va parler des drivers propriétaires, mais ils sont déjà cassés (à l'exécution) de temps à autre avec le modèle actuel (nVidia et le 4K_STACK, les drivers linuxant n'ont pas encore tourné sans Oops sur toute la série des 2.6.* que j'ai utilisé, ...), donc ça ne sera pas réellement pire.
[^] # Re: Question ?
Posté par Matthieu Moy (site web personnel) . Évalué à 9.
Tu ne crois pas si bien dire : Les utilisateurs du driver eagle pour les modems sagem ont déjà eu : "Mes drivers sont pour 2.6.4 et je suis en 2.6.5 !! Argh !!" Parce que les API de l'usb avaient changé dans le noyau.
[^] # Re: Question ?
Posté par Anonyme . Évalué à 0.
La 2.4 et la 2.6 ne sont pas des stables. Trop régulierement des éléments experimentaux y sont introduits.
[^] # Re: Question ?
Posté par tgl . Évalué à 10.
> Trop régulierement des éléments experimentaux y sont introduits.
Les éléments introduits au fil des 2.6 ne sont pas expérimentaux. Ils sont passés par la branche -mm avant d'être intégrés, et ça n'est que là qu'ils étaient expérimentaux.
Ce qu'il faut bien voir, c'est qu'il n'y a aucune garantie qu'une mise à jour entre deux noyau 2.6 vanilla puisse être faite sans la moindre conséquence sur le reste du système. C'est plutôt du côté des noyaux des distributions qu'il faut se tourner si on veut pouvoir faire des mises à jour sans se poser de question. C'est à eux de fournir des ensemble noyau + drivers externes + outils userspace cohérents. L'utilisateur qui par contre se jette tête baissée sur le dernier vanilla le fait à ses risques et périls. Cette situation était clairement assez criticable tant qu'elle n'était pas annoncée noir sur blanc, mais maintenant que c'est fait, je n'y vois rien à redire.
Un truc intérressant à noter aussi c'est qu'il est serieusement envisagé, si il y a de la demande, de faire des backports des correctifs les plus importantes entre les versions mineures des 2.6 vanilla. Ainsi, si on est en 2.6.x et qu'il y a une nouvelle faille corrigée, ça ne serait pas en 2.6.(x+1) qu'il faudrait upgrader (enfin pas si on veut une stabilité au sens "rien de neuf"), mais plutôt en 2.6.x.1. Ça fournirait bien la même garantie de stabilité que des noyaux de distrib, mais sans imposer toutes les features additionnelles et parfois douteuses qui sont souvent livrées avec.
[^] # Re: Question ?
Posté par Laurent Martelli (site web personnel) . Évalué à 4.
Tant qu'on aura pas une stabilité des APIs du noyau, Linux sera toujours à la traîne pour les drivers de matériel récent, car les constructeurs ne peuvent pas fournir les drivers avec le matériel vendu avec la certitude que ça marchera sur tel ou tel noyau.
Et qu'on ne me réponde pas que les constructeurs n'ont qu'à publier leur specs pour qu'on puisse développer des drivers livres. Les distribs ne peuvent pas se permettre de sortir une nouvelle version à chaque qu'apparaît une nouvelle carte graphique ou une nouvelle carte son.
La stabilité de l'API permettrait d'avoir un programme de certification et on pourrait reconnaître facilement le matériel supporté grâce à un petit logo "Linux 2.4 compliant" sur la boite par exemple.
[^] # Re: Question ?
Posté par tgl . Évalué à 9.
Tu crois sincèrement qu'il est là le problème ? Les quelques constructeurs qui veulent sortir des drivers pour Linux n'ont pas de difficultée à le faire. Quelques semaines après le passage de la pile à 4Ko, c'est à dire bien avant que ça ne se retrouve dans la moindre distrib' Linux et que donc ça ne pause le moindre problème aux utilisateurs (sauf à qlqs geeks accrocs à kernel.org qui croient que leur système va s'autodétruire si ils n'utilisent pas la dernière version en date), des drivers NVidia corrigeant l'overflow sont sortis. Non, franchement, si beaucoup de constructeurs ne font pas de drivers Linux, ça n'est pas parcequ'il est trop mouvant ou je ne sais quoi, c'est juste parcequ'ils n'en n'ont rien à foutre des 1% de clients que ça pourrait intéresser.
Quant à l'histoire du logo, bof, pour moi ce qui serait à vérifier pour l'attribuer, ça n'est pas qu'il existe un driver qui va éternellement marcher sur toute la série des 2.X, mais plutôt qu'il y a un drivers qui marche avec les 2.X actuels, et un constructeur qui va le mettre à jour de façon à ce que ça continue. Moi ça me parait parfaitement acceptable de dire, et c'est ça qui compte, que « les NVidia sont supportée sous Linux avec la 3D et tout et tout via un driver proprio ». Alors que pourtant il y a effectivement eu qlqs semaines pendant lesquels ça n'était pas vrai pour la toute dernière version du noyau, mais je vais pas pinailler pour ça.
Accessoirement, quand bien même il y aurait une API à 100% figée pour une série de noyaux, ça ne voudrait pas dire qu'on peut certifier qu'un driver proprio marchera avec 2.X.Z sous prétexte qu'il marche avec 2.X.Y . Rien ne garantit en effet qu'elle n'est pas contournée et qu'il n'y a pas dans le code du driver des hacks qui créeront des incompatibilitées avec des versions futures à cause de changement internes au noyau, ne modifiant pourtant pas l'API. Donc une certification telle que tu l'entends, elle me parait bien illusoire.
[^] # Re: Question ?
Posté par Philippe F (site web personnel) . Évalué à 1.
> pas dans le code du driver des hacks qui créeront des
> incompatibilitées avec des versions futures à cause de changement
> internes au noyau
Oui, mais dans ce cas, tu peux faire un report de bug clair incriminant le driver. Maintenant, la situation, ce sera "ca marche pas" sans que tu saches si un truc subtil a change dans le noyau, dans le driver, si le driver est code comme un pied ou si tu as un probleme sur ta machine.
Personellement, je considere ce modele de developpement comme une regression. Certe Linus aura moins de difficulte. Par contre, ca va etre la merde pour tout le monde en dehors de ceux qui suivent la lkml.
Les noyaux vont etre beaucoup moins testes par les utilisateurs puisqu'une mise a jour deviendra une operation tres dangereuse si on n'est pas sur de maitriser.
De tres gros projets arrivent tres bien a gerer l'evolution d'une base de code stable avec une evolution rapide (Mozilla, KDE, Gnome, Qt, Gtk) tout en conservant la compabilite binaire. Je ne vois pas pourquoi le noyau n'y arriverait pas. En fait, si , je vois tres bien. C'est parce que ca ne plait pas a Linus. C'est pas assez fun, c'est bien plus fun de tout peter a tout moment parce que ca nous plait que de conserver des API mouvante parce que soi-disant, ca va ameliorer la qualite des drivers.
Plus ca va, plus Linus fout la merde dans Linux. Mais c'est son bebe, on n'a rien a dire.
La phase "mais non, c'est pas dur de recompiler son noyau" ne pourra plus etre valable du tout.
Ca m'enerve vraiment. Quand je vois tous les efforts deployes par Trolltech, KDE ou Gnome pour qu'une mise a jour incompatible des lib se passe le plus tranquillement possible du monde, j'admire. Ils ne font ca que tous les 2 a 4 ans, ils preparent de bibliotheques de compabilite, ils preparent les developpeurs pendant plusieurs mois en faisant des snapshots, ils communiques, ils reflechissent longtemp a l'avance a ce qu'ils vont changer.
Linus, lui s'en bat tout simplement les couilles et je trouve ca dommage. Il a toujours eu cette attitude mais la ca devient vraiment genant. Le 2.6 ne pourra plus etre considere comme un noyau de reference.
[^] # Re: Question ?
Posté par tgl . Évalué à 0.
[^] # Re: Question ?
Posté par Guillaume CASTAGNINO (site web personnel) . Évalué à 6.
On aboutirais alors a quelque chose comme windows XP qui peut encore faire tourner des applis DOS au détriment de la qualité du support des applis 32 bits. Ou des processeurs x86 encore basés sur leur vieille structure 8 bits !! tout ça pour garder la compatibilité... D'ailleurs, on voit bien qu'une architecture comme l'IA64 qui s'affranchissait de ce passé n'a pas vraiment pris
Laisser de coté la compatibilité ascendante a certes des inconvénients puisque cela demande des mises a jour plus lourdes, mais cela permet de s'affranchir du passé parfois lourd en problemes et erreurs de conception du programme, et il faut parfois ce rendre compte qu'en continuant a trainer une compatibilité ascendante, on traine un boulet qui empeche de vraiment évoluer...
[^] # Re: Question ?
Posté par Laurent Martelli (site web personnel) . Évalué à 3.
Et il est en général possible de garder une couche de compatibilité quand on introduit une nouvelle API.
[^] # Re: Question ?
Posté par pasBill pasGates . Évalué à 7.
C'est vrai, mais il y a des limites.
Une API c'est l'equivalent d'un contrat, tu dis aux gens qui vont utiliser ton API :
"Voila les gars, les choses vont marcher comme cela, promis, vous pouvez les utiliser maintenant"
Quand tu t'amuses a casser ton API a chaque version, les gars n'ont plus du tout confiance en toi, ils en ont marre de devoir retoucher leur code et sortir une nouvelle version a chaque fois, se taper le support des gens qui leur demandent pourquoi ca marche plus,...
Bref, tu perds tes clients quand tu les mene en bateau trop souvent, meme chose avec les API.
La bonne facon de faire c'est soit :
1) Reflechir profondemment aux changements a faire, et changer l'architecture rarement, histoire de faire comprendre aux gens "on sait c'est chiant, mais fallait vraiment le faire"
2) Garder l'ancien API et introduire un nouveau en parrallele tout en marquant l'ancien obsolete avec indication claire que l'ancien disparaitra d'ici x periode.
On aboutirais alors a quelque chose comme windows XP qui peut encore faire tourner des applis DOS au détriment de la qualité du support des applis 32 bits
Tu m'expliqueras ou est le probleme...
Les applis DOS tournent grace a une machine virtuelle, l'OS en lui-meme ne fait rien pour garder la compatibilite DOS.
[^] # Re: Question ?
Posté par Philippe F (site web personnel) . Évalué à 6.
Oui. Je pense que c'est le probleme no 1.
> Les quelques constructeurs qui veulent sortir des drivers pour Linux n'ont pas de difficultée à le faire.
Non. Les quelques constructeurs hyper motives qui veulent sortir des drivers pour Linux y arrivent tant bien que mal apres beaucoup d'efforts.
Imagine une boite qui fait un peripherique a la con. 95% de son marche est sous windows, 5% sous Linux (je suis tres optimiste, normalement, c'est 99.99999% ). Elle passe 2 ans a developper son driver avec son equipe de 2 personnes et il marche sous tous les windows. Elle est contente.
Mainenant, cette boite n'a aucun a priori sur Linux. Elle se dit que ca pourrait etre sympa de recuperer les 5% restant. De toute facon, sa version windows ne lui coute en maintenance que quelques jours-hommes par an donc elle a un tout petit peu de temps libre.
Voila qu'elle decouvre que si elle veut faire des drivers pour Linux, il faut qu'elle les fasse pour une version de Linux donnee. Ensuite, il faut qq'un qui suive en permanence l'evolution du kernel pour garantir que le driver n'est pas pete a chaque seconde qui passe. Sa maintenance va se chiffrer en mois-hommes parce que tout Linus a decide que l'api utilisee par le driver etait de toute facon pourrie et obsolete et va donc re-ecrire un truc completement incompable.
On imagine que la boite suit cette premiere transition. Apres, bien que le truc ait ete re-ecrit, il y encore des modifs a apporter a l'API du machin qui sont faites tranquillement, sans communiquer plus que un message sur la lkml, et qui petent le driver de nouveau.
Pour resumer, en terme de cout, un driver sous Linux, c'est quelque mois-hommes par an alors que le marche lui-meme est beaucoup plus faible que sous windows.
Le choix est vite fait pour n'importe quelle entreprise, il n'y aura pas de driver pour Linux. Mais ca Linus s'en fout apparemment.
[^] # Re: Question ?
Posté par DiZ . Évalué à -3.
[^] # Re: Question ?
Posté par pasBill pasGates . Évalué à 7.
- Mettre le driver en libre
- Ne pas faire de driver
Ben c'est con pour les linuxiens, parce que la grande majorite des constructeurs choisissent le cas 2)
Une petite lecon tres utile : Quand on n'est pas en position de force, il est tres difficile de forcer les gens a faire ce qu'on veut, donc au debut vaut mieux brosser les constructeurs dans le sens du poil.
[^] # Re: Question ?
Posté par DiZ . Évalué à -1.
>choisissent le cas 2)
Tant pis pour eux. Je n'achète pas leur matèriel.
Ils auront au moins perdu un client.
[^] # Re: Question ?
Posté par wismerhill . Évalué à 7.
[^] # Re: Question ?
Posté par DiZ . Évalué à 1.
>"ça ne marche pas".
Je n'ai pas envie d'imposer Linux a qui que ce soit. Il s'impose de lui même et il s'est déjà imposé de lui même dans beaucoup de domaine avec un support bien moindre que de nos jour, et sans drivers propiétaire.
[^] # Re: Question ?
Posté par Pierre LALET . Évalué à 6.
Compare le coût de développement pour eux d'un driver pour Linux par rapport à ce qu'ils ont à y gagner. Tu crois vraiment que perdre un client leur fera beaucoup de peine ?
Tu n'a pas l'impression de faire l'autruche en disant tant pis pour eux ? Finalement, tu n'achètes pas le matériel que tu aurais choisi, et tu en choisis un autre, moins bien et/ou plus cher (vu que ce n'était pas ton premier choix), et encore, quand il existe un matériel de substitution, ce qui n'est pas évident. Donc tu es plus perdant qu'eux. Ce n'est pas en niant cela que l'on peut faire changer les choses.
[^] # Re: Question ?
Posté par DiZ . Évalué à 1.
Pesonnellement je ne veux pas de "logiciel" propriétaire de "bas niveau".
Cela me dégage des éventuelles problèmes de maintenance (version du noyau), de support des développeurs noyau, de pérénité ...
Je n'ai pas encore trouvé de matèriel qui ne possèdait pas de "drivers" libre pour mes besoins et j'espère ne pas en avoir dans le future
>Compare le coût de développement pour eux d'un driver pour Linux par
>rapportà ce qu'ils ont à y gagner
Je ne leur demande absolument pas de développer des drivers propriétaire pour Linux.
La façon dont la communauté est organiser ne correspond surement pas au mode de développement de logiciel propriétaire (trop de distrib, "Nouveau modèle de développement pour Linux" :-) , release trop fréquente, mode de packaging différent.
Seul posséder les sources et avoir une communauté active permet de suivre ce mode de développement.
Il suffirait de permettre aux développeurs de faire des drivers libres...
[^] # Re: Question ?
Posté par majinboo . Évalué à 2.
Maintenant faut quand meme dire que les drivers sous linux c'est autrement plus compliqué à mettre en place que sous windows. (par exemple : impossible de mettre en place les drivers ATI + nforce2 sur un 2.6 alors que la meme ATI sur une mobo chipset VIA passe impec' avec le 2.6)
[^] # Re: Question ?
Posté par Croconux . Évalué à 6.
On ne leur demande pas forcément de développer des drivers clé en main. Ils peuvent aussi fournir des specs. On ne leur demande pas de réveller le fonctionnement interne de leur matériel mais juste ce qu'il faut faire pour que ça tourne. Là, c'est comme si en voulant acheter une voiture on te répondait: "Ah non, désolé vous ne pouvez pas la conduire. Vous devez acheter la voiture avec le chauffeur (de chez nous) qui vous emmenera où vous voudrez. On ne peut pas vous montrer comment conduire cette voiture celà dévoilerait nos super secrets de fabrication que même la NASA nous envie".
Surtout que souvent on se demande bien ce qu'il y a de secret. Il me semble qu'il n'y a toujours pas de driver livre pour le chipset réseau du NForce2. C'est clair qu'un pauvre chip 10/100 c'est trop high tech. Il ne faudrait pas que la concurrence découvre comment fabriquer une carte réseau. Ce serait la fin du monde.
[^] # Re: Question ?
Posté par Laurent Martelli (site web personnel) . Évalué à 1.
Une API ce n'est pas seulement des noms de fonction. C'est aussi un comportement. Et il est très facile de vérifier quelles sont les symboles requis par module.
[^] # Re: Question ?
Posté par Guillaume Knispel . Évalué à -2.
Et qu'on ne me réponde pas que les constructeurs n'ont qu'à publier leur specs pour qu'on puisse développer des drivers livres. Les distribs ne peuvent pas se permettre de sortir une nouvelle version à chaque qu'apparaît une nouvelle carte graphique ou une nouvelle carte son.
C'est quoi cet argument à 2 balles ? Tu ne veux pas des specs pcq les distri sortiront pas instantanement à chaque nouvelle CG ? Mais n'importe quoi ! Avec un drivers proprio la problématique ne change pas ! C'est pas la liberté du driver qui empeche de le télécharger ou le fait qu'il soit proprio qui empeche de l'inclure dans une distri (<- selon la licence pour certains c'est en effet impossible, mais là n'est pas mon propos)
[^] # Re: Question ?
Posté par Laurent Martelli (site web personnel) . Évalué à 2.
Que connais-tu de mes besoins ? Windows ne me convient pas pour beaucoup de raisons.
Relis mon message. J'ai dit que fournir les specs ne change rien au problème. Problème qui est que si une nouvelle carte sort 3 mois après la dernière version de ta distrib préférée, c'est quand-même plus sympa d'avoir un driver avec la carte (surtout pour une carte réseau). Et si ta distrib inclut un changement d'API datant d'après l'écriture du driver ,t'es dans la mouise.
Et de toutes façons, s'il faut gérer 15 versions d'API, c'est la galère pour celui qui écrit le driver.
Le changement et le progrès c'est bien, mais on ne peut rien bâtir sur du sable mouvant. Il faut savoir fixer certains chose afin de faciliter la tâche de ceux qui en dépendent. Si on veut favoriser l'écriture de drivers pour Linux, il faut figer les APIs, sinon peu de gens se donnerons la peine de fournir des drivers compatibles avec toutes les versions.
[^] # Re: Question ?
Posté par Guillaume Knispel . Évalué à 10.
Que connais-tu de mes besoins ? Windows ne me convient pas pour beaucoup de raisons.
Bah je disais ca parce que tu voulais des certifications et des autocollants, et ca me fait un peu dresser les cheveux sur la tete. Pourquoi pas obliger les codeur à coder en costard cravate ;)
Relis mon message. J'ai dit que fournir les specs ne change rien au problème. Problème qui est que si une nouvelle carte sort 3 mois après la dernière version de ta distrib préférée, c'est quand-même plus sympa d'avoir un driver avec la carte (surtout pour une carte réseau). Et si ta distrib inclut un changement d'API datant d'après l'écriture du driver ,t'es dans la mouise.
Plus je le relis moins je le comprends ! Je suis d'accord pour dire avec toi que les changement d'API CMAL (pour faire cours). Mais je suis pas ton exemple :
Soit une distri, soit une carte qui sort 3 mois apres, tu souhaites avoir un driver pour ta carte (entre nous tu pourrais acheter des cartes dont tu sais qu'elles fonctionnent mais bon tu fais ce que tu veux). Et la l'API est plus récente dans ta distri d'il y a 3 mois que dans le driver tout neuf ? Ca serait pas plutôt l'inverse ?
De tout facon tu as raison dans un cas comme dans l'autre le driver ne marchera pas, bref.
Mais de là à dire qu'on s'en fout que les constructeurs donnent pas les specs.... C'est insuportable ! La seule maniere d'avoir une pérénité avec du matériel est d'avoir les SPECS !!! Combien de temps crois tu que ta gentille entreprise qui fait du proprio va supporter le driver (pour le bidule moyen, pas pour le truc ultra courant d'une multinationnale monopolistique qui a les moyens) ? 2 ans peut etre, et là au bout de 2 ans il est probable qu'effectivement quelques API soient incompatible (je suis pour la stabilité des API, mais 2 ans me semble être une période infiniment longue en matière de logiciel libre). Sous Win figure toi que le problème et le même, et pourtant la pérénité des API est supérieure : les drivers pour différents OS pourtant de la même architecture (9x ou NT) sont des fois different selon que tu as 95, 98, ME ou NT 2K ou XP (avec quand meme plus de stabilite dans la derniere famille). Parce que bien souvent de subtiles changement entrainent tout un tas de complication, et que l'interface seule ne garantie pas une compatibilité à 100%, et on voit mal comment elle pourrait le faire sachant que l'interface est la parti visible d'une architecture complexe en perpetuelle (r)evolution.
Bref tout ca pour dire qu'API stable ou pas, des problèmes annexes feront que au bout de 2 ans tu pourra de toute facon mettre ton bidule à la poubelle si la boite ne daigne pas continuer à assurer de support, et là POUF ! Tu comprends soudain l'interet des spécifications : Pourquoi crois tu que ma carte son SB16 fonctionne toujours aussi bien depuis 10 ans ? Crois moi que sans spec et avec des drivers proprio ca fait longtemps que Creative Labs aurait abandonné le support Linux.... (et vu l'age qu'elle a ils n'aurait de toute facon pas eu le temps de le commencer ce fameux support).
L'absence de Spec est une véritable plaie ! Des gens s'énervent à reverser plein de truc en l'absence de spec pour que tu puisses avoir ton petit confort (Samba, NTFS, Drivers de plein de matos, ...). Moi même en ce moment je reverse le driver d'une putain de WebCam et ca commence même à me saouler. Et crois moi qu'API ou pas API, le constructeur ne filera jamais ni driver proprio ni spec parceque c'est des nains qui ont envient de proteger leur "propriété intellectuelle" (oui oui, une description du format ca risque certainement de mettre leur Sté en péril mon dieu) et que le marché de Nux pour les WebCam doit etre ridicule. Alors si ton souhait est d'avoir un driver proprio par périphérique de ta machine je te suggère de reconsiderer fortement l'interet du libre pour toi. Parce que le but de Linux s'est pas de fournir une plate forme de référence pour drivers et appli proprio, mais bien que tout soit ouvert afin qu'on puisse faire des changements librements sans dépendre du bon vouloir de son fournisseur de matos. Et je te rappelle que historiquement le libre est nait parce qu'un driver d'imprimante proprio buggait ca mere et que ca a saoulé stallman au plus au point. Et bien figure toi que cette situation arrive aujourd'hui tous les jours avec des putains de drivers à la con, et que dans ce cas ta seule solution est d'aller pleurer chez Monsieur NVidia ou Monsieur ATI pour qu'ils arretent d'écrire n'importe quoi. Moi au lieu d'aller pleurer, je préfererais hacker tranquillement leur bidule et leur envoyer un patch.
Alors merde, oui je VEUX avoir les specs du matos que j'ai, et crois moi bien que je les aurait par tous les moyens légaux voir illégaux si ca continue a me saouler autant, et toi je réitère ma proposition de retourner sous Win ou tu profitera d'une API pérene et de pleins de drivers proprios.
[^] # Re: Question ?
Posté par Laurent Martelli (site web personnel) . Évalué à 0.
Je n'ai jamais dis ça. Juste que ça n'apporte pas grand chose au problème du support de matos récent.
Je pense tout comme toi qu'il faut avoir des specs pour des raisons de pérennité.
[^] # Re: Question ?
Posté par Sébastien TeRMiToR . Évalué à 1.
c pas un probleme de spec ! et tu es bien voilent je trouve , à dire: "tu n'as cas etre libre sinon tu es un nain" !
le libre c bien , mais tu imposse pas la liberté !
on veut des drivers libre principalement , mais meme pour cela , j'en ai mare de voir que une fois ce marche et une fois cela ne marche pas !
de voir qu'il faut recompiler un kernel pour le support de ceci cela
imagine tu as 500-1000-5000 voire 20000 drivers, tu imagine le travail de maintenance sur un bordel de code pariel
il faut des api, il faut pouvoir separé le noyau en morceau compilable separement!
mais la , compiler linux c choisir les bonnes option est espere que cela ne plante pas!
se mode de dev "marchote' pour le momment, mais on arrive quand meme a la saturation , si on peut plus faire confiance au derniere version d'un noyau mais ou va ton ! je veux pouvoir mettre des nouveau drivers sans tous recompiler possible ? non
la flexibilité d'avoir les source d'un logiciel c bien , mais cela ne remplace pas la flexibilité au niveau binaire
sinon on pourrais se contenté d'un gnome avec un enorme fichier source de 50mo , qui genererais un executable , ca serais tellement pratique
[^] # Re: Question ?
Posté par Christophe Lucas (site web personnel) . Évalué à 1.
C'est quoi ta webcam ??
T'as déjà demander au support ? au producteur de ta webcam ?
Pour ma part, ils n'ont pas rechigner à me dire quel type de capteur il avait mis dans leur bignou.
Vas voir sur : http://go.lamarinapunto.com(...) peut-être que l'un des capteurs supportés est le tien :-)
- Christophe
# lien intéressant sur l'article de LWN et al.
Posté par oliv . Évalué à 10.
http://article.gmane.org/gmane.linux.kernel/219718/match=anvin(...)
# 2.7.x
Posté par Mazz . Évalué à 0.
Y a t-il justement des infos sur les parties du noyaux 2.6 qui seraient suceptibles d'etre modifiées pour lancer la branche 2.7 ?
# utilitaires pour recompiler perso les noyaux patchés des distros
Posté par free2.org . Évalué à 2.
Je viens d'en voir un experimental pour Debian: sourcerer-kernel-builder
Il recompile un noyau perso dès que le noyau Debian est modifié (patchs de sécurité et de stabilité principalement)
http://packages.debian.org/experimental/admin/sourcerer-kernel-buil(...)
[^] # Re: utilitaires pour recompiler perso les noyaux patchés des distros
Posté par GhZaaark3 . Évalué à 2.
franchement je suis fort déçu de la série 2.6
elle ne m'apporte que des problèmes
y a t-il vraiment quelques chose à en tirer? les linux-threads valent t-ils la peine?
j'ai un 2.4.26 qui tourne au poil et même mieux que je pourrais l'espèrer
alors pourquoi changer me direz vous? l'evolutivité, l'optimisation tjrs accrue.
j'attendrais tout de même une version 2.7 du noyau
[^] # Re: utilitaires pour recompiler perso les noyaux patchés des distros
Posté par GhZaaark3 . Évalué à 2.
que ce noyau m'a tout de même étonné, on sent les accélèrations, la stabilité et fluidité quand on fait plusieurs choses en même temps (compilation+surf)
mais voilà c'est bien maigre car ça ne dure pas longtemps ou quand on utilise le système de normalement, le 2.6 accuse des problème de stabilités.
ça fait un peu comme un windows installé tout frais, la première heure c'est fluide, la seconde tu peux réinstaller.
[^] # Re: utilitaires pour recompiler perso les noyaux patchés des distros
Posté par Guillaume CASTAGNINO (site web personnel) . Évalué à 4.
Des latences diminuées, un meilleur support de mon matos (carte mère récente, etc...), mon disque a pris 10Mo/s sur un hdparm -tT, je suis franchement très content des NPTL et du 4kb Stack qui tous deux contribuent a réduire la charge qui pese sur le système, et tous mes serveurs s'en portent très bien, que ce soit apache, proftpd ou postgresql ou mysql...
Franchement, je n'ai que des points positifs
[^] # Re: utilitaires pour recompiler perso les noyaux patchés des distros
Posté par GhZaaark3 . Évalué à 1.
ma wacom marche plus
et les pilotes nvidia sont ralentis. (un effet de rafraichissement génant sur le dessin des fenêtres)
[^] # Re: utilitaires pour recompiler perso les noyaux patchés des distros
Posté par Christophe Lucas (site web personnel) . Évalué à 3.
Je pense donc que tu devrais écumer les diverses ML afin de trouver pourquoi tu as dse manques de stabilité.
Bon samedi à tous :-) et vive les espadrilles (non non aucune référence explicite à la pub des nuls n'est en vigueur ici ;-) )!!
En tout cas bon samedi et bonnes vacances à ceux qui en ont ...
-- Christophe.
[^] # Re: utilitaires pour recompiler perso les noyaux patchés des distros
Posté par GhZaaark3 . Évalué à 1.
le dernier en fait, et c'est vrai qu'on le sent, c'est le jour et la nuit.
c'est d'une fluidité fulgurante, et j'ai même gagné 300pts à glxgear (même si c'est plutôt relatif comme référence)
je n'ai plus ce problème de rafraichissement désagréable avec les pilotes nvidia.
mais j'ai changé tellement de choses en même temps, il m'est très difficile d'identifier les tenants et les aboutissants
remarque, je ne peux pas encore activer le ntpl car j'utilise un 2.4.26 pour ma tablette wacom USB qui a du mal de chez mal avec un noyau 2.6.x, mais bon le problème a déjà été signalé... patientons avant l'affranchissement total :).
Toutefois ceci m'amène une question, y a t-il une grosse différence avec le nptl activé? ce n'est pas vitale?
encore une fois, on est bridé par le matos.
[^] # [HS] Tablette WACOM
Posté par ceituna (site web personnel) . Évalué à 1.
Et tu en est content de ta tablette wacom ? Tu as des pointeurs intéressants ?
Ca je m'en suis acheté une ce WE, et je suis moyennement satisfait du résultat... :(
ce qui m'ebête le plus, c'est le manque de précision... Dommage pour une tablette... :(
[^] # Re: [HS] Tablette WACOM
Posté par GhZaaark3 . Évalué à 1.
la sensibilité est bien présente.
Concernant ton appréhension, tu ne l'as que depuis un weekend, y a un temps d'adaptation.
Mais c'est vrai que pour certaines formes elliptiques, c'est pas evident, mais ça vient de la tablette ou de ta façon de tenir le stylet.
Tu devrais essayer Cinepaint, en plus d'avoir une très précision irréprochable, il offre un panel de brosses très intéressante.
on l'aura compris je suis assez satisfait du support, et c'est un travail formidable initié par Frederic LePied!
mais je peine pour la faire fonctionner sur un noyau 2.6 dont je ne peux plus me passer.
+
# Petite rétrospective
Posté par Jérôme Pinot (site web personnel) . Évalué à 1.
Linux-2.6.0-test5 (septembre 2003)
http://linuxfr.org/~ngc891/5233.html(...)
Kernel 2.6.0-test11 (novembre 2003)
http://linuxfr.org/~ngc891/7203.html(...)
Le kernel 2.6.0 stable, c'est pas pour demain (novembre 2003)
http://linuxfr.org/~ngc891/7275.html(...)
Linux 2.6.6 (mai 2004)
http://linuxfr.org/~ngc891/12544.html(...)
Et surtout:
Kernel 2.6, 6 mois après (mai 2004)
http://linuxfr.org/~ngc891/13160.html(...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.