Articles : Une plongée dans le développement de Linux
Posté par pbegou (). Modéré le 15 décembre 2006.
Comparez avec Vista qui est sorti dans la douleur, au bout de 5 années de développement effectué derrière des portes fermées.
Mon article, essayant de décrire tout ce processus, est disponible sur Internet sous forme Wiki (donc éditable par tous). Les améliorations seront les bienvenues, je cherche en particulier de l'aide pour les chapitres consacrés aux distributions Fedora, Ubuntu, SuSE, etc.
![[fr]](../images/fr.png)
LibreProcess (3108 hits)
> Lire la dépêche (114 commentaires, moyenne: 3).
Vous avez demandé le commentaire #785641.
Faut pas exagerer...
Depuis ce tout début, ce cycle de développement s'est un peu ralenti, cependant le noyau Linux continue à évoluer à un rythme très rapide comparé aux logiciels à source fermé (Windows XP est sorti fin 2001 et Windows Vista est attendu pour début 2007): une version 2.6.x toutes les 7 à 8 semaines comme indiqué dans le tableau ci-dessous:
Faudrait aussi te rendre compte qu'entre XP et Vista il y a eu :
a) 2 service packs
b) D'innombrables patchs au kernel
Quand au processus soi-disant ferme, c'est evidemment pas aussi transparent que Linux, mais il y a plein d'info disponibles sur ce qui a change, pourquoi, ...
[^]Re: Faut pas exagerer...
Puis vu la totale instabilité de l'API du kernel linux c'est pas vraiment une gloire de sortir des versions comme on change de chemises.
[^]Re: Faut pas exagerer...
Puis vu la totale instabilité de l'API du kernel linux c'est pas vraiment une gloire de sortir des versions comme on change de chemises.
Le standard ISO Posix a changé sans prévenir ?
Sans compter les applications qui utilisent des bibliothèques portables: java, gtk,qt,wx,python,tcl...
Il me semble que ce sont surtout les API spéciales marquées "experimental" qui changent, et on est donc au courant de leur instabilité quand on les utilise. Il y a aussi "deprecated" pour prévenir à l'avance qu'une API sera un jour enlevée.
[^]Re: Faut pas exagerer...
Il parle du kernel et de l'ABI pour les drivers, pas des librairies qui tournent sous Linux
[^]API=Application Programming Interface, Posix
API=Application Programming Interface
Le standard ISO Posix a toujours été le principal ensemble d'API offert par le noyau Linux.
ABI=Application Binary Interface
[^]Re: API=Application Programming Interface, Posix
Moi je te propose de te renseigner un peu plus avant de sortir des acronymes et prendre leurs mots au sens basique du terme, t'auras l'air plus credible...
[+] [^]Re: API=Application Programming Interface, Posix
cite tes sources puisque tu es bien renseigné
[^]Re: API=Application Programming Interface, Posix
une API est ensemble de fonctions ou classes répondant à un certain domaine.
Tu as POSIX qui offre une API de base, mais on ne te DIT pas comment elle doit être implémentée. mais simplement que son interface doit respecter une norme, d'où la norme POSIX :d
En dessous de l'API Posix, tu as d'autres API, celle du kernel, qui n'est jamais exportée pour les autres softs.
Crois-tu que ton "open" est une simple fonction ??? Et les syscalls, ils servent à quoi ?
[^]Re: Faut pas exagerer...
Justement on t'attendais. Que nous proposes tu pour sortir de cette impasse ? Et dans ta vie à toi tout seul, ça t'a beaucoup dérangé l'instabilité des API/ABI du noyau ?
M.
eucd.info : sauvons le droit d'auteur !!!
[^]Re: Faut pas exagerer...
Moi personnellement je ça m'a beaucoup dérangé. Quand on a un pilote libre qui fonctionne avec un kernel version x et qui ne marche plus avec la version x+1, on peut supposer que c'est assez dérangeant. Bien entendu, ils pourraient demander à se faire inclure au kernel. Mais bon chacun à ses raisons, toussa.
Moi comme solution, je proposerais un truc dans le style : Bien penser l'API à l'avance pour la garder le plus longtemps possible. Et si y'a des changements bah faire du versionning d'API et essayer de garder le support de chaque version de l'API. C'est surement beaucoup de taf mais est ce qu'il y a beaucoup plus de travail à maintenir les API plutot que changer tous les drivers dés qu'on fait un changement dans l'API ?
[^]Re: Faut pas exagerer...
Vous l'avez surement déjà lu mais les raisons pour lesquelles Linux ne veut pas d'API interne stable sont expliquées ici:
/usr/src/linux/Documentation/stable_api_nonsense.txt
Bien sûr, ça ne concerne pas les API entre le noyau et les applications utilisateurs qui, elles, sont stables.
[^]Re: Faut pas exagerer...
Un pilote libre wifi que j'utilisais demandait des retouches manuelles dans ses sources presque toutes les 0.0.2 versions du kernel qui passent.
En comparaison j'ai des vieux pilotes proprio qui marchent toujours sous Vista.
Les attaques gratuites sur windows, ça va deux minutes. Là j'aurais rien dit sur la stabilité des API si vous ne teniez pas le bâton pour vous faire battre.
Depuis ce tout début, ce cycle de développement s'est un peu ralenti, cependant le noyau Linux continue à évoluer à un rythme très rapide comparé aux logiciels à source fermé (Windows XP est sorti fin 2001 et Windows Vista est attendu pour début 2007): une version 2.6.x toutes les 7 à 8 semaines comme indiqué dans le tableau ci-dessous:
Moi, perso, je m'en branle qu'il "évolue à un rythme très rapide" si ça veut dire casser tous les pilotes qui n'ont pas été bénis et sanctifiés par sa Sainteté Linus.
[^]Re: Faut pas exagerer...
lis ça : http://lxr.linux.no/source/Documentation/stable_api_nonsense(...) avant de raconter des anneries.
Moi, perso, je m'en branle qu'il "évolue à un rythme très rapide" si ça veut dire casser tous les pilotes qui n'ont pas été bénis et sanctifiés par sa Sainteté Linus."
Sois le driver joue le jeu et est dans le tronc commun et il est mis à jour à chaque modification d'api, soit il n'est pas dedans et se gère tout seul comme un fork !
[^]Re: Faut pas exagerer...
Répéter la propagande des développeurs kernel ne change rien aux faits. Sous windows on code un driver et on y touche plus pour très longtemps. Sous linux si t'as un driver qui n'est pas dans le tronc tu peux te le foutre dans l'oignon.
[^]Re: Faut pas exagerer...
Sous windows on code un driver et on y touche plus pour très longtemps
c'est tellement vrai ce que tu dis. Je te raconte meme pas les enormes trous de securite qui en resulte et ce pendant des annees. Apres c'est tellement stable l'API windows que tout plein de scanner (par exemple) n'ont pas supporte le passage win98 -> winXP et la meme histoire est en train de se repeter avec Vista mais bon c'est vrai c'est pas la faute de MS juste celui des boites tel que Canon qui refusent de faire un drivers pour Vista (enfin l'API n'ayant pas change cela aurait meme pas du exister comme probleme...)
[+] [^]Re: Faut pas exagerer...
c'est tellement vrai ce que tu dis. Je te raconte meme pas les enormes trous de securite qui en resulte et ce pendant des annees
Vas y, donne moi donc ces trous de securite qui sont le resultat d'une ABI stable, j'attends et je vais bien rire je sens.
Apres c'est tellement stable l'API windows que tout plein de scanner (par exemple) n'ont pas supporte le passage win98 -> winXP
Si tu reflechissais 2 secondes, tu te rendrais compte que WinXP c'est pas la version suivante de Win98 mais un OS totalement different avec un kernel completement different.
et la meme histoire est en train de se repeter avec Vista mais bon c'est vrai c'est pas la faute de MS juste celui des boites tel que Canon qui refusent de faire un drivers pour Vista (enfin l'API n'ayant pas change cela aurait meme pas du exister comme probleme...)
C'est au contraire la preuve que MS fait des changements quand il faut les faire, la grosse difference etant qu'ils ne les font que quand c'est absolument necessaire et dans l'enorme majorite des cas les drivers continuent de tourner.
[^]Re: Faut pas exagerer...
PasBill pasGates : Si tu reflechissais 2 secondes, tu te rendrais compte que WinXP c'est pas la version suivante de Win98 mais un OS totalement different avec un kernel completement different.
taratatatata : En comparaison j'ai des vieux pilotes proprio qui marchent toujours sous Vista.
Que dois-je croire ? que les pilotes proprio fonctionnent toujours si changement de version de windows, ou qu'ils peuvent ne pas fonctionner car kernel différent ?
[^]Re: Faut pas exagerer...
Non, simplement comprendre qu'il y a 2 lignees d'OS chez MS :
Win9x : Win95, 98, Millenium
WinNT : NT4, W2k, XP, WS03, Vista
Les drivers sont senses fonctionner dans une lignee, pas forcement passer d'une lignee a l'autre sans dommage. C'est 2 types d'OS completement differents qui n'ont rien a voir l'un avec l'autre, meme si il y a une couche de compatibilite.
Bref, ca revient a dire : Tu peux t'attendre a ce que ton driver fonctionne quand tu passes du kernel 2.4 au 2.6 ou du 2.6.2 au 2.6.4, mais faut pas t'attendre a ce que ton driver fonctionne si tu passes du kernel Linux au kernel freeBSD
[^]Re: Faut pas exagerer...
Non, simplement comprendre qu'il y a 2 lignees d'OS chez MS :
Win9x : Win95, 98, Millenium
Tu consideres vraiment Millenium comme un OS? Tu dois etre la seule personne a le penser.
[^]Re: Faut pas exagerer...
A l'epoque il etait certainement plus utilisable malgre ses defauts par la majorite du public que n'importe quelle version de Linux, donc oui, a moins que tu consideres que Linux n'etait pas un OS a l'epoque.
[^]Re: Faut pas exagerer...
A bon? Linux etait pas utilisable en 2000? Je veux bien admettre que c'etait pas focement simple a installer mais a utiliser c'etait deja utilisable et surtout stable. Windows millenium ce fut jamais utilisable meme Microsoft deconseillais son utilisation (une fois que tu avais la licence naturellement).
Millenium n'etait pas utilisable, linux si sinon l'OS qui tournait sur les pc de ma boite a l'epoque devaient etre magique.
[^]Re: Faut pas exagerer...
Linux a toujours été plus performant et utilisable que Windows.
déjà en 1993 Linux vs Windows 3 c'est sans comparaison tellement Linux été supérieur.
2 ans plus tard en 1995, Linux était encore largement supérieur à Windows 95. Disons 150 BSOD contre 0 kernel panic ! Un DOS 16 bits avec une GUI vs un système full 32 bits multi utilisateurs. Un système qui ne crois pas en Internet vs un système qui est construit grace à Internet...
Seulement a cette époque, la communauté Linux n'avait pas les moyen de se payer les Rollings Stones pour se faire de la pub !
[^]Re: Faut pas exagerer...
Et avait vim comme traitement de texte.
[^]Re: Faut pas exagerer...
> Et avait vim comme traitement de texte.
Mais aussi
StarOffice, Wordperfect, Applixware, Siag Office...
[^]Re: Faut pas exagerer...
Exact, en pas libre (pour les premiers au moins.) Applis qui tournaient aussi sous d'autres Unix si je ne m'abuse.
Je précise, c'est par rapport à cette histoire de driver proprios dans d'autres discussions.
[^]Re: Faut pas exagerer...
WordPerfect n'est apparu qu'en 1998
StarOffice etait inutilisable et crashait constamment(ils venaient de faire le port) en 1996
...
A croire que tu n'as aucune idee de quoi tu parles.
[^]Re: Faut pas exagerer...
>Linux a toujours été plus performant et utilisable que Windows.
Ridicule:
*performance: je me souviens d'un benchmark fait par Microsoft ou Linux se faisait taper par Windows, certes c'était un benchmark pas tres intéressant mais dire que "Linux a toujours été plus performant que Windows" est donc faux, 'Linux est généralement plus performant Windows' est vrai par contre.
* utilisable: la je suppose que tu parles de l'OS (l'utilisatibilité d'un noyau, bof): ce qui est dans bien des cas totalement faux: les fournisseurs de matériels fournissent des pilotes pour Windows et rarement pour Linux, donc il y a plus de matériel compatible Windows que Linux, donc pour ce matériel la, Windows est plus utilisable que Linux, pareil pour les logiciels (bien plus de logiciels disponible pour Windows que pour Linux), et la compatibilité avec les standards de fait (.doc, .xls, etc).
Etre sur linuxfr n'implique pas de se mettre la tête dans le sable et dire des c*** comme quoi Linux est plus fort que tout, il faut savoir rester réaliste.
[^]Re: Faut pas exagerer...
D'un autre côté faut essayer de ne pas contredire des conneries par d'autres :
- Même si c'est vrai, quel crédit peut-on avoir d'un benchmark fait par Microsoft entre Windows et Linux ? franchement ! c'est comme l'autolabel max havelaar !! ou comme si nvidia faisait un benchmark de ces cartes avec ATI et disait que les cartes nvidia étaient plus rapides !!
- les fournisseurs de matériels fournissent des pilotes pour Windows et rarement pour Linux, donc il y a plus de matériel compatible Windows que Linux : c'est marrant, moi qui croyait que Linux était l'OS qui supportait le plus de matériel ! tu ne serais pas en train de généraliser entre le matériel grand public et le matériel en général ? ton affirmation "il y a plus de matériel compatible Windows que Linux" est délirante, surtout qu'il faut distinguer Windows 9x et Windows NT (2000, XP...).
- etre compatible avec les pseudo-standards de fait ne fait pas un OS plus performant et utilisable. Avec Linux, tu as toujours pu écrire une lettre ou ton CV avec un traitement de texte (qui depuis on disparu de la circulation).
[^]Re: Faut pas exagerer...
>quel crédit peut-on avoir d'un benchmark fait par Microsoft entre Windows et Linux ?
Le benchmark en question (me souvient plus trop mais c'était une histoire de servir des pages web sur un multi-processeur) était débile, mais les mesures refaites par des supporters de Linux ont établi que la supériorité de Windows dans ce cas la était réelle (depuis cela a été corrigé): donc le toujours est bien faux.
>c'est marrant, moi qui croyait que Linux était l'OS qui supportait le plus de matériel
Tu finasse: Linux "de base" supporte plus de matériel que Windows "de base", mais comme le matériel vient avec un CD de driver pour Windows, il y a quand même plus de matériel utilisable sous Windows en final que sous Linux.
Et je parle bien sur de WindowsXP, le standard a l'heure actuel.
>- etre compatible avec les pseudo-standards de fait ne fait pas un OS plus performant et utilisable. Avec Linux, tu as toujours pu écrire une lettre ou ton CV avec un traitement de texte (qui depuis on disparu de la circulation).
Ah bon, ne pas pouvoir éditer simplement des documents dans un format utilisé par une énorme majorité des entreprises, cela ne rend pas un OS moins utilisable??
C'est beau la mauvaise foi!
La dernière foi que j'ai essayé d'ouvrir un .doc de ma boite avec OOo le résultat était loin d'être terrible: le formatage du document était complement foiré (ok depuis il y a eu plusieurs versions d'OOo) donc on utilise Crossover office, mais c'est loin d'être parfait: super-gourmand, se met souvent a utiliser 100% du CPU, crash parfois, etc..
[^]Re: Faut pas exagerer...
Tu finasse: Linux "de base" supporte plus de matériel que Windows "de base", mais comme le matériel vient avec un CD de driver pour Windows, il y a quand même plus de matériel utilisable sous Windows en final que sous Linux.
Et je parle bien sur de WindowsXP, le standard a l'heure actuel.
- Au boulot nous avons des cartes d'acquisition qui ne fonctionne pas sous Windows XP.
- la phrase initiale que tu as contredite prenait en compte toutes les versions de windows et de linux, et pas seulement windows XP.
- j'ai connu un scanner agfa scsi qui ne fonctionnait que sous win98
Et je parle bien sur de WindowsXP, le standard à l'heure actuelle.
WindowsXP n'est pas un standard mais un système d'exploitation très utilisé à la maison, mais moins en entreprise qui pour beaucoup en sont encore à windows 2000. Il ne faut pas généraliser en encensant WindowsXP de standard. C'est comme si je disais que Apache était un standard sur le web!
Ah bon, ne pas pouvoir éditer simplement des documents dans un format utilisé par une énorme majorité des entreprises, cela ne rend pas un OS moins utilisable??
Le fait que Word soit utilisé dans la majorité des entreprises ne fait pas de windows un système plus performant. De plus, étant dans le monde du travail de l'informatique depuis plus de 7 ans, je dois avouer n'avoir jamais eu l'occasion d'éditer un document d'une autre entreprise. Les seuls documents que j'ai reçu de l'extérieur sont des PDF afin que je ne puisse pas les éditer. Ah si, je suis un peu de mauvaise fois, des fois je reçois des méls avec des documents words, mais ils auraient été en PDF, ça aurait fait la même chose (ou mieux, l'auteur aurait écrit son texte dans le mél m'aurait éviter de devoir lancer une application tierce pour lire le message). Donc je n'ai jamais eu besoin d'éditer un document venant de l'extérieur.
Et puis, si j'avais du le faire, j'aurais demander à la personne du RTF.
La dernière foi que j'ai essayé d'ouvrir un .doc de ma boite avec OOo le résultat était loin d'être terrible: le formatage du document était complement foiré (ok depuis il y a eu plusieurs versions d'OOo) donc on utilise Crossover office, mais c'est loin d'être parfait: super-gourmand, se met souvent a utiliser 100% du CPU, crash parfois, etc..
Moi aussi, ça me le faisait il y a quelques années. Depuis, j'arrive à lire le texte et avoir une présentation convenable. Et puis si ce n'est pas identique, ce n'est pas grave, l'important est le contenu, pas le contenant.
De plus, il m'arrive aussi d'avoir des crashs avec word. Donc on n'a pas de solution idéale (word) face à une solution dégradée (oo), mais deux solutions qui ont chacune leurs avantages.
[^]Re: Faut pas exagerer...
Biensur que concerver la qualité du document original est primodial, même si c'est pas l'essentiel , il en va de la crédibilité de ton logiciel.
- J'ai ouvert ton .doc avec Ooo j'ai changer les choses qui n'allait pas je te le refile...
- Ok... mais... t'as tout explosé ma mise en page?
- C'est normal, Ooo n'arrive pas à supporter correctement le format fermé de Word, c'est pourquoi blablabla
- hummm
- tu comprends?
- Soit. Je comprend surtout que tu vas me faire le plaisir de recommencer ce que tu vient de faire avec MS Word, merci, j'ai pas que ça à faire.
- mais Ooo plante pas...
- T sûr? pourquoi tu n'arrives à pas ouvrir ce document et que tu le redémarre sans cesse alors?
- disons.... moins... ok il plante aussi. Mais il n'a pas la procédure de recovery de document en cas de plantage, ce qui va te faire perdre un temps CPU indispensable.
- Tu vois la porte?
[^]Re: Faut pas exagerer...
Pour ce qui est du matériel tu es de mauvaise foi, on peut toujours trouver un matériel X accessible que sous un OS exotique, mais si tu vas dans n'importe quel grand magasin et que tu achetes du materiel, il sera fourni avec un pilote Windows XP, pas autre chose.
> WindowsXP n'est pas un standard
OK, disons l'OS majoritairement utilisé.
>C'est comme si je disais que Apache était un standard sur le web!
Dans le sens ou j'utilisais 'standard', c'est presque le cas..
>Le fait que Word soit utilisé dans la majorité des entreprises ne fait pas de windows un système plus performant.
Performant non, utilisable oui.
>n'avoir jamais eu l'occasion d'éditer un document d'une autre entreprise.
Et alors? Dans mon entreprise, le standard est .doc (comme dans une grande majorité des entreprise), et oui on s'édite mutuellement des docs.
Si je demande a l'expéditeur de me fournir un RTF, il m'envera bouler: la boite a choisi de se standardiser sur .doc, il y a même des templates de documents a utiliser.
Cela peut changer: avant le standard pour la doc technique était interleaf, mais ce genre de migration est lourd et compliquée a faire.
Mouai, je ne dirais jamais que Word est idéal (personnellement je déteste Word), n'empèche que pour éditer des .doc, ça reste plus simple d'utiliser Office sous Windows que sous Linux, et donc l'OS est plus utilisable de ce point de vue.
[^]Re: Faut pas exagerer...
Pour ce qui est du matériel tu es de mauvaise foi, on peut toujours trouver un matériel X accessible que sous un OS exotique, mais si tu vas dans n'importe quel grand magasin et que tu achetes du materiel, il sera fourni avec un pilote Windows XP, pas autre chose.
Le problème est que le matériel d'acquisition ne se trouve pas en magasin grand public. Quand tu dis que Windows XP supporte tous les matériels, je corriges en disant que Windows XP supporte tous les matériels que tu peux acheter dans les magasins grand public. Là où je travaille, nous nous coltinons encore des win98 et winNT uniquement à cause de matériels non supportés sous XP.
Dans le sens ou j'utilisais 'standard', c'est presque le cas..
mais vaut mieux utiliser un autre mot que "standard", car toi tu comprends ce que tu veux dire, mais d'autres vont l'interprêter autrement. Tu connais le téléphone arabe ?
Et alors? Dans mon entreprise, le standard est .doc (comme dans une grande majorité des entreprise), et oui on s'édite mutuellement des docs.
Intra-entreprise, oui, et je ne comprendrais pas qu'il n'y ait pas de politique commune dans le choix des standards. Mais je parlais des échanges inter-entreprise qui sont souvent avancés par argument pour utiliser tel logiciel, mais que de mon vivant, je n'ai pas encore vu.
Donc en conclusion, on pourrait dire que Windows est plus utilisable que Linux pour la façon dont on a décidé de l'utiliser. Mais on aurait très bien pu faire la même chose avec Linux.
[^]Re: Faut pas exagerer...
> donc il y a plus de matériel compatible Windows que Linux
Dans tes rèves !!
Linux tourne sur la quasi totalité des architectures informatiques existantes, du périphériques embarques aux supercalculateurs.
Il tourne sur tout type de station de travail (sparc, powerpc, mips, ...). Il supporte des dizaines de milliers de périphériques toutes architectures confondues...
Franchement, Windows est à la traine et même incroyablement selectif quand au matériel sur lequel il peut tourner. Et avec Vista ça ne s'arrange pas, bien au contraire.
[+] [^]Re: Faut pas exagerer...
Ca on s'en fout, l'enorme majorite des gens veut un OS qui fonctionne avec le matos qu'ils ont ou qu'ils trouvent dans les grand magasins, et la c'est vite vu.
Tu peux toujours t'amuser a aller prendre des cas speciaux et exotiques, ca ne changera pas la realite, ca renforcera juste tes frustrations.
[^]Re: Faut pas exagerer...
oui, et pourquoi Windows est-il fourni d'office avec les machines neuves ?
tout simplement parce que sous windows, l'intrégration système, la gestion des drivers sur le matériel récent est aussi casse-tete que sur linux, pour ne pas dire plus compliqué.
Donc ma conclusion est : pourquoi ca marche sous windows, "en sortant du caddy" : parce qu'un intégrateur à fait le boulot avant toi.
Alors je relance la balle : si j'achete un PC tout intégré sous Linux, je suis presque certain de trouver la même facilité d'utilisation, puisque c'est l'intégrateur qui aurait tout le travail.
Maintenant, si on sort de ce contexte intégration, je crois bien que Windows et Linux se valent. En gros, le résultat est fonction de la direction du vent, de la température extérieure, de la couleur de la jupe de Ségolène, de l'indice du CAC 40 ....
[^]Re: Faut pas exagerer...
>pourquoi Windows est-il fourni d'office avec les machines neuves ?
Parce que plus de 90% des utilisateurs utilisent Windows? Parce que Microsoft fait payer une license Windows pour tout les PC vendus par le fabriquant?
>l'intégration système, la gestion des drivers sur le matériel récent est aussi casse-tete que sur linux, pour ne pas dire plus compliqué.
Faux, du matériel récent n'a souvent pas de pilote Linux, alors le fabriquant fourni le pilote pour Windows.
> si j'achete un PC tout intégré sous Linux, je suis presque certain de trouver la même facilité d'utilisation, puisque c'est l'intégrateur qui aurait tout le travail.
En théorie oui, en pratique j'ai déja vue des revue de PC 'tout intégré sous Linux' ou le seul boulot fait par l'intégrateur était de prendre une distrib Linux de l'installer sur le PC et si la carte Wifi ne fonctionne pas, tant pis..
> je crois bien que Windows et Linux se valent.
Pour la majorité des utilisateurs, à l'heure actuelle et leur besoins (bureautique, jeux), je dirais que Windows est supérieur a Linux sauf que les problèmes de sécurité de Windows annulent tous gain voire même désavantage Windows, sauf pour ceux qui savent sécuriser Windows, ce qui est hors de portée du débutant mais quand même pas si compliqué..
[^]Re: Faut pas exagerer...
bonne argument :-)
C'est vrai que pour le PC spécial ado (webcam de carrefour, imprimante de chez Aldi, dernière carte ATI/NVidia/Autre flambant neuve) il n'y pas souvent de drivers pour linux.
En revanche, faire tourner windows 2000 sur Sparc ou MS SQL Server sur AIX, c'est très dur.
[^]Re: Faut pas exagerer...
bah le PC spécial ado, s'il a plus d'un an, il ne tournera pas non plus sur la prochaine version de Windows faute de drivers non plus hein...
[^]Re: Faut pas exagerer...
Comme l'a dit pasBill pasGates, ce n'est plus du tout le même OS. Y'a les mêmes API pour les applications mais l'os en dessous n'a rien à voir.
Quand je parle de vieux pilotes qui marchent sous vista, je parle de pilotes pour Windows 2000. Qui est de la lignée NT5.
Ca fait donc un driver qui utilise les API d'un kernel vieux de 7 ans. Ce même driver fonctionne sur l'os qui va sortir en 2007.
En comparaison des cassures qu'on peut constater entre chaque versions du kernel 2.6 qui est tout jeune.. y'a pas photo. Le 2.6 est sorti en décembre 2003 et n'en a pas fini de casser les API comme je change de chemises. Et c'est pas avec des développeurs comme Greg Kroah-Hartman qu'on va changer la donne..
[^]Re: Faut pas exagerer...
Quand je parle de vieux pilotes qui marchent sous vista, je parle de pilotes pour Windows 2000. Qui est de la lignée NT5.
Ca fait donc un driver qui utilise les API d'un kernel vieux de 7 ans. Ce même driver fonctionne sur l'os qui va sortir en 2007.
ouhias enfin tous les drivers windows2000 ont pas trop supporte le passage a XP donc celui a Vista je doute enormement.
[^]L'hopital qui se fout de la charité....
ben ouais, tiens c'est marrant, mon scaner agfa e26, ben c'est con il ne marche pas sous XP, Agfa a arreté de faire des scanner alors que le drivers ne gerait que du 2000. domage...
et oui, c'est vrai, "on code un driver et on y touche plus pour tres longtemps" : en effet, s'il s'écoule 5 ans entre 2 version de windows, ton assertion est parfaitment juste, mais c'est uniquement a cause du retards de microsoft, parcequ'en attendant il est plutôt d'actualité que les drivers sous vista se font attendre.
(c'est con pour toi, car c'est justement pas le moment pour sortir ce genre de connerie...)
[^]Re: L'hopital qui se fout de la charité....
Ben le monsieur au dessus (pbpg) qui a l'air de s'y connaitre dans windows l dit que c'est la meme famille d'OS 2000 et XP. Je comprend rien moi comment ca peut avoir casser le driver alors?
[+] [^]Re: L'hopital qui se fout de la charité....
Si tu lisais attentivement tu aurais lu :
C'est au contraire la preuve que MS fait des changements quand il faut les faire, la grosse difference etant qu'ils ne les font que quand c'est absolument necessaire et dans l'enorme majorite des cas les drivers continuent de tourner.
Ce qui explique que l'enorme majorite des drivesr pour 2000 tournent sans probleme sur XP et WS03.
Prendre les qqe cas ou ca ne marche pas ne va pas changer la realite pour l'enorme majorite des drivers.
[^]Re: L'hopital qui se fout de la charité....
Prendre les qqe cas ou ca ne marche pas ne va pas changer la realite pour l'enorme majorite des drivers.
idem pour les drivers linux!
[+] [^]Re: L'hopital qui se fout de la charité....
Prends des binaires de drivers Linux de 2001, essaie de les faire tourner sur un kernel d'aujourd'hui, compte combien tournent.
Je te paries mes 2 bras qu'il y en aura tres tres peu.
[^]Re: L'hopital qui se fout de la charité....
jusqu'a maintenant (dans ce journal) je trouvais tes interventions bien plus cohérente que celles taratatata, mais là c'est limite un troll, effectuer une comparaison entre windows en 2001 et celui de fin 2006 : il s'agit du même (vista n'est pas encore sortie concretement, pas de boite a la fnac, et pas dans le shipment msdn pro de decembre). donc en fait.
comparer windows XP (2001) et windows XP sp2 (2006)
ce n'est pas la même chose que de comparer un kernel 2.4.3 et un 2.6.19
sinon, je suis d'accord, on ne peux pas faire une généralités d'un cas personnel (le mien avec mon agfa en l'occurrence).
[+] [^]Re: L'hopital qui se fout de la charité....
Ben Vista est dispo ici, tu peux l'acheter a CompUSA par exemple aujourd'hui. Sinon il y a Windows Server 2003 aussi, et on peut partir de Windows 2000 en 2000 si tu veux, ca ne change rien.
[^]Re: L'hopital qui se fout de la charité....
Prends des binaires de drivers Linux de 2001, essaie de les faire tourner sur un kernel d'aujourd'hui
Ne le prends pas mal, mais c'est un peu con de vouloir faire ça !
[^]Re: L'hopital qui se fout de la charité....
C'est surtout inutile, car "la grande majorité" du materiel supporté par Linux en 2001 est toujours supporté sur un kernel d'aujourd'hui.
Et même si ce n'est pas le cas, la disponibilité des sources fait que le portage reste possible, donc en fait tout materiel supporté à une certaine époque peut être porté dans toute version plus récente.
Évidemment dans le monde fermé, il ne reste que les yeux pour pleurer quand le constructeur refuse de porter le-dit driver...
[^]Re: L'hopital qui se fout de la charité....
peut etre est-ce pour garder les bonnes habitudes acquisent sous windows, utiliser des drivers bien troues et qui marchottent a peine?
Enfin personnelement je prefere avoir des drivers qui evoluent avec le temps et pas uniquement avec le matos...
[^]Re: Faut pas exagerer...
Sois le driver joue le jeu et est dans le tronc commun et il est mis à jour à chaque modification d'api, soit il n'est pas dedans et se gère tout seul comme un fork !
Ah elle est jolie la philosophie de l'interopérabilité ! Ah elle est jolie la critique de MS lorsqu'ils cassent la compatibilité avec un standard ! Faudrait standardiser les interfaces du kernel pour rigoler tiens. Heuresement que à la couche supérieur y'a eu POSIX, sinon j'imagine même pas dans quel bordel on serait. C'est pas au même étage, mais les problématiques sont les mêmes. Linus & Co veulent tout maîtriser et veulent forcer tout le monde à rentrer dans leur tronc commun (sous peine d'être un driver de seconde classe jamais synchronisé tellement ca change souvent).
C'est quand même pas compliqué de conserver un API tel quel, et d'en faire un nouveau en repartant de 0 à côté, les 2 pouvant marcher côte côte, l'un pour les anciens drivers, l'autre pour les nouveaux.
Non, faut dire ce qui est, garder la compatibilité, ca les fait chier. Ca serait pourtant plus simple que de perdre son temps à continuellement modifier une énorme base de driver.
Une API de qualité est avant tout une API conçue pour être pérenne dans le temps, bref, conçu pour le présent et l'avenir. Le fait d'avoir les sources et la main mise sur l'ensemble des drivers ne doit pas être une excuse pour occulter ce manque de qualité.
Enfin ca me fait marrer cette comparaison avec le fork... En tout cas ca montre bien le modèle de développement du kernel : complètement fermé vers l'extérieur. Ils veulent tout maîtriser, ils en ont rien à péter de s'interfacer avec des briques extérieures. Logiciel libre avec une interface fermée, ca me paraît à l'opposé philosophiquement. C'est quand même rigolo, à l'époque où les Unix étaient tous proprio, eux avait pensé interopérabilité avec POSIX.
Exemple de problème de pérénité dans le temps : en tant qu'utilisateur j'aimerai qu'on me laisse ma liberté de conserver des anciens pilotes tout en en profitant des mises-à-jour de pilotes plus récent. Non, le noyau me laisse pas le choix, si t'upgrade, faut tout upgrader. Et non, les maj n'apporte pas que des améliorations, y'a aussi parfois des régressions.
MonoFrance
[^]Re: Faut pas exagerer...
Bon, je vais supposer que tu as lu le document déjà donné deux ou trois fois précédemment. L'API interne ne concerne que ... la tambouille interne du noyau. Mais ledit document précise bien un truc : si jamais quelqu'un modifie une api, c'est à sa charge de répercuter le changement d'API sur le code noyau, i.e. l'intérêt de tout ça c'est la factorisation de code, et d'avoir à effectuer le moins de changement dans les pilotes eux-mêmes. Si ces derniers sont inclus dans le noyau officiel, alors oui, ils seront aussi modifiés en conséquence ; sinon, c'est à charge de celui qui fournit le pilote de le modifier. Ça me semble assez logique, finalement.
Le côté « oui mais bon, les API stables, ça permet de pouvoir garder une compatibilité plus longtemps, etc » ne tient pas selon moi dans une optique de logiciel libre, car si tu fais du code hors-noyau (le plus souvent propriétaire), alors de toute façon il ne te reste plus qu'à maintenir un seul et unique driver - ce qui suppose que tu suis les changements opérés dans le noyau, certes, mais d'un autre côté, ça fait partie du jeu : de ce que j'ai compris, seuls les pilotes codés avec les pieds [1] et ceux qui sont proprio sont concernés, au final. Dans le premier cas, je comprends qu'une équipe de développement n'ait pas envie de servir de debugger pour un pilote qui gagnerait à être proprifié. Dans le deuxième, si tu fais du propriétaire, et tu assumes un chouilla. Ça ne me semble pas démesuré, comme principe.
Pour faire un rapide résumé/traduction de stable_api_nonsense.txt :
- Croire qu'avec une API stable, on obtient une ABI stable est faux, car suivant le compilateur utilisé, par exemple, les alignements, lef ait d'inliner certaines fonctions, etc. changent ; stabilité = nil.
- suivant les options noyau choisies, on se retrouve avec des champs qui apparaissent ou disparaissent dans les structures, l'alignement va changer, etc. ;
- Il y a tout plein d'architectures différentes supportées par linux ; aucune compatibilité binaire entre elles donc.
Donc on se retrouve avec l'obligation de devoir utiliser un compilateur pour une distribution et une architecture spécifiques, si on veut pouvoir garder cette propriété de stabilité. Sans parler du côté SMP/SMT/CMP/MonoProc qu'on doit choisir...
Je m'arrête là. Comme il a été dit plus tôt ( https://linuxfr.org/comments/785368.html#785368 ) tout cela tient plus au modèle choisi qu'à quelqu'un ayant tort ou raison. Par contre, si pour un OS comme celui de MS (ou d'Apple, d'ailleurs), utiliser une seule architecture ainsi qu'un seul noyau permet de réduire fortement les inconvénients cités précédemment, je ne vois pas comment Linux pourrait faire de même.
[1] D'après les critères de qualité de l'équipe de dév. du noyau, certes.
[^]Re: Faut pas exagerer...
Croire qu'avec une API stable, on obtient une ABI stable est faux, car suivant le compilateur utilisé, par exemple, les alignements, lef ait d'inliner certaines fonctions, etc. changent ; stabilité = nil.
Je suis bien d'accord. C'est par contre un problème purement technique, lié au langage C (pourri pour ce qui est de faire des ABI stable). Mais à la limite je m'en cogne d'avoir des ABI stable, on est dans le monde libre, je veux bien me "taper" la recompilation d'un driver.
Je demande pas la compatibilité binaire, juste une compatibilité au niveau source. Bref, des API stables.
MonoFrance
[^]Re: Faut pas exagerer...
ben elles existent.
les API tels quels sont stables
Par contre la tambouille interne au noyau ... ben elle est interne au noyau , et pas forcément stable.
Enfin c'est ce que j'ai compris.
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: Faut pas exagerer...
Le truc c'est qu'ils considèrent que les API des drivers sont de la tambouille interne, genre comme si les drivers faisaient partie intégrante du noyau.
MonoFrance
[^]Re: Faut pas exagerer...
Ben c'est absolument le cas, d'un point de vue technique. Les pilotes s'exécutent dans l'espace mémoire du noyau, avec ses droits d'accès, ses privilèges, sa capacité à tout péter... Aucun moyen de se protéger d'un pilote, qui peut d'ailleurs altérer tout le comportement du noyau s'il le souhaite.
[^]Re: Faut pas exagerer...
D'un point de vu droit d'exécution oui. D'un point de vu purement technique non. Bien qu'étant un noyau monolithique à la base, Linux est quand même suffisament bien foutu pour accepter des drivers "externes", d'où la présence des APIs. Ce qui les rend pas "user-friendly", c'est la façon dont ils sont maintenus. Y'a aucune raison de cantonner les drivers au processus interne de dev du noyau, ca doit ête externaliser pour que tout le monde puisse développer ses propres drivers sans subir la politique d'évolution du kernel. Evidemment, ca demande un minimum de boulot d'ingénierie de la part du noyau.
Et puis si on en revient à la question des privilèges utilisateurs, il n'est pas non plus pertinent de faire tourner l'ensemble des drivers avec les droits du noyau. Si un grand nombre de driver tourne encore dans cet espace de droit, c'est simplement pour des questions techniques (vitesse toussa), mais d'un point de vue architectural c'est pas du tout préconisé. Pour comparer avec un OS proprio dernière génération, beaucoup de drivers sont gérés avec un niveau de droit inférieurs aux droits du kernel lui même, voir même en espace utilisateur.
Evidemment, tout cela demande une refonte technique et politique du noyau Linux, mais ca reste un objectif de qualité qu'ils devraient se fixer, et visiblement ils s'en cognent. Si tu veux développer ton driver et que tu n'as pas l'intention de l'incorporer dans la branche principal, ils ne font rien pour t'aider, tu te démerdes pour suivre ces API "internes".
MonoFrance
[^]Re: Faut pas exagerer...
Evidemment, tout cela demande une refonte technique et politique du noyau Linux, mais ca reste un objectif de qualité qu'ils devraient se fixer, et visiblement ils s'en cognent. Si tu veux développer ton driver et que tu n'as pas l'intention de l'incorporer dans la branche principal, ils ne font rien pour t'aider, tu te démerdes pour suivre ces API "internes".
Rien ne t'empeche de patcher linux, le forker , contribuer à HURD, ou encore à nemesis.
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: Faut pas exagerer...
Rien ne t'empeche de patcher linux, le forker , contribuer à HURD, ou encore à nemesis.
Comme je l'ai déjà expliqué, Linux contribue à "tuer" les initiatives concurrentes : le nerf de la guerre, c'est les drivers. Hors Linux rend non viable tous fork de son noyau (au risque de devoir forker et maintenir tous les drivers), et difficile toute alternative : les drivers ne peuvent être réutiliser.
je trouve vraiment dommage cette politique qui nuit clairement à la réutilisation (pourtant un des gros atouts des logiciels libres) et à la création d'alternatives.
Après l'initiative freedesktop, faudrait une initiative freekernel :)
MonoFrance
[^]Re: Faut pas exagerer...
Ha ça y est, t'as trouvé un sujet sur lequel te défouler :
Ce dont on parle n'a rien à voir avec un standard, c'est la cuisine interne du noyau. Critique gratuite à 2 fr qui n'a rien à voir avec le sujet.
Justement, ce qu'on dit c'est l'interface utilisateur <-> kernel est plus ou moins "standard" (de fait), contrairement aux API internes.
Bah justement, comme c'est à un niveau plus élevé, c'est d'une certaine manière plus facile à respecter, puisque le "sens" de l'API est plus élevé, et qu'on est pas dans la cuisine bas-niveau.
Ha oui, bien sûr, la conspiration contre les petits développeurs et les constructeurs ...
Ho non, ça demande juste de recoder complètement une partie du noyau tout en en maintenant une autre, soit à peu près le double d'effort.
Pour un exemple de compications dues à ça, regarde le temps qu'il faut pour intégrer la pile ieee80211 de Devicescape : ça fait un bout de temps qu'on en parle et qu'elle est toujours pas upstream, et pendant ce temps il faut continuer à faire évoluer en parallèle celle d'Intel.
Oui, ça les fait chier de garder des anciennes API pourries pour les beaux yeux de contructeurs qui font du proprio et veulent des API bien stables.
Ils ne perdent pas leur temps à adapter les drivers puisqu'ils devront bien s'adapter un jour à cette nouvelle API !
Oui c'est mieux d'avoir une API stable, mais ce n'est pas toujours possible. Le kernel avance très vite, et c'est cela qui a beaucoup bousculé le monde proprio : les changements d'API arrivent donc plus souvent, et d'un coté c'est clair que la disposition des sources incite d'autant plus à ne pas se restreindre à une vieille API car le mode de développement du libre permet de facilement faire évoluer tous les drivers ensemble.
N'importe quoi, les changements assez profonds sont prévus à l'avance, bien documentés. Par contre, ils n'en ont effectivement rien à péter que des gens leurs imposent leur méthodes de travail : le libre avance comme ça et c'est tout. C'est le même genre de tendance qu'on a vu arriver avec le changement d'ABI d'Xorg 7.1 : certains utilisateurs ce sont mis à critiquer les packageurs de mettre Xorg 7.1 dans leur distro car NVidia et ATI n'avaient pas encore sorti de drivers compatibles avec la nouvelle API ! Ce n'est pas au monde du proprio de dicter la manière dont doivent évoluer les déveoppeurs. Dans le libre, ceux qui peuvent avoir un poid sur les discussions, ce sont ceux qui jouent le jeu du libre. Et donc surement pas NVidia et ATI.
Encore du n'importe quoi, les changements sont généralement documentés.
Arf, comme tu dis au début de ton commentaire, Linux est toujours compatible POSIX malgré les changements dont on parle ici, heureusement. Encore du n'importe quoi.
Alors là, tu pousses un peu le bouchon : tu utilises le mot liberté pour obtenir arbitrairement des choses des gens, ce qui montre bien ton intolérance. Moi aussi j'aimerais bien avoir la liberté de te faire fermer ta gueule des fois, mais bon ...
PS: Désolé pour la vulgarité, mais te voir dire tant de bêtises et te faire plusser ça m'énerve
[^]Re: Faut pas exagerer...
Ce dont on parle n'a rien à voir avec un standard, c'est la cuisine interne du noyau.
Ah non non. On parle interface de driver. Et ce que justement je dénonce c'est cette volonté de vouloir "fermé" le noyau en déclarant "c'est de la tambouille interne".
Justement, ce qu'on dit c'est l'interface utilisateur <-> kernel est plus ou moins "standard" (de fait), contrairement aux API internes.
Pour moi l'interface des drivers du noyau constitue pleinement une interface utilisateur. Tout du moins ca devrait l'être.
Ho non, ça demande juste de recoder complètement une partie du noyau tout en en maintenant une autre, soit à peu près le double d'effort.
Ah bah oui, un code de qualité, c'est sûr, ca demande plus d'effort, que voulez vous ma petite dame, on peut pas tout avoir, la liberté et la qualité. Moi je dénonce au passage que ce manque de qualité est à mettre en corrélation avec un mode de développement fermé, ce que je trouve vraiment dommage dans le monde des logiciels libres.
Oui, ça les fait chier de garder des anciennes API pourries pour les beaux yeux de contructeurs qui font du proprio et veulent des API bien stables.
Mais je parle pas de proprio du remarqueras. Je parles aussi des drivers en général.
Ils ne perdent pas leur temps à adapter les drivers puisqu'ils devront bien s'adapter un jour à cette nouvelle API !
T'as déjà développé en groupe ou quoi ? Entre faire 15 passes successives sur un même code pour acoucher d'un truc bancal et une réécriture propre tu trouves que c'est où la perte de temps ?
Oui c'est mieux d'avoir une API stable, mais ce n'est pas toujours possible. Le kernel avance très vite, et c'est cela qui a beaucoup bousculé le monde proprio :
Ca c'est effectivement la situation actuelle. Moi je râle sur ces changements incessant. Evidemment qu'il ne faut pas rester avec des API "figés". Que y'es des gros changement de Linux 2.4 à 2.6, je comprend. Qu'il y en ai tous les mois voir toutes les semaines, ca devient hallucinant. Les API qui "cassent" la compatibilité avec l'existant devrait apparaître dans les versions majeures, tous les 2 ans (je donne l'ordre de grandeur).
N'importe quoi, les changements assez profonds sont prévus à l'avance, bien documentés.
C'est pas n'importe quoi, ca change beaucoup trop souvent.
C'est le même genre de tendance qu'on a vu arriver avec le changement d'ABI d'Xorg 7.1 : certains utilisateurs ce sont mis à critiquer les packageurs de mettre Xorg 7.1 dans leur distro car NVidia et ATI n'avaient pas encore sorti de drivers compatibles avec la nouvelle API !
Mouarf, arrête de parler du problème du proprio. Enlève du sujet le proprio tu veux bien. Moi tu vois lors de l'intégration du pilote libre Gatos dans X.org (gestion des tuner et I/O video des cartes Radeon AIW), j'ai tout simplement vu disparaître un grand nombre de fonctionnalité de ma carte graphique. Youplaboum. Je fais quoi : je reste avec l'ancienne version ? Je maintiens moi même dans mon coin un driver que je dois modifier à chaque fois que les API changent ? Merci bien. C'est pas un problème de proprio/libre, c'est un problème général. Et j'en ai marre d'entendre cette excuse à 2 francs, limite on casse les API exprès pour faire chier le proprio. Et c'est la même chose à chaque fois : "pourquoi vous cassez les API ?" "Proprio c mal toussa". Où comment chercher des excuses philosophiques à des problèmes techniques. Du grand n'importe quoi (:-p)
Encore du n'importe quoi, les changements sont généralement documentés.
Pour moi un API qui change tout le temps, ca revient à faire une API fermée. La documentation n'est pas le saint graal. "Ah j'ai documenté, demerdez vous !".
Arf, comme tu dis au début de ton commentaire, Linux est toujours compatible POSIX malgré les changements dont on parle ici, heureusement. Encore du n'importe quoi.
Arrête avec ton "n'importe quoi". Tu fais exprès de pas comprendre. Je voulais dire qu'une des seules normes que le noyau suit, c'est l'interface POSIX, imposée dans un monde proprio. Ils avaient des bonnes pratiques à l'époque, il n'y a pas de raison de ne pas les utiliser aujourd'hui dans le monde libre. C'est pour ca que j'ironisait au début en disant qu'il faudrait standardiser les API de drivers du noyau, histoire de.
tu utilises le mot liberté pour obtenir arbitrairement des choses des gens, ce qui montre bien ton intolérance.
Houlà, mais je suis pas intolérant, je respecte le choix des développeurs du noyau, je serais inccapable de faire ce qu'ils font, mais en tant qu'utilisateur je donne mon avis. Enfin si on me pertinente, c'est que certains sont peut être dans la même situation que moi, à savoir de simple utilisateur qui aimerait voir leur noyau plus stable.
PS: Désolé pour la vulgarité, mais te voir dire tant de bêtises et te faire plusser ça m'énerve
C'est vrai que quand on prend un tout petit bout d'une phrase, en virant le contexte, en faisant samblant de pas comprendre ce que le type a voulu dire, et en disant "n'importe quoi" toutes les 2 lignes, ont doit vite s'énerver.
Un truc aussi qui m'énerve dans cette situation : Linux s'impose comme impossible à forker. J'entend par là que c'est pas demain la veille qu'on aura une alternative à Linux. Pas d'API stables pour les drivers ? Pas de couche d'abstraction du fonctionnement sous-jacent. Et donc pas d'alternative possible au coeur du noyau sans un fork de l'ensemble des drivers. Moi j'aimerai bien avoir une banque de driver "réutilisable" avec des vrais alternatives quand au noyau utilisé dessous.
MonoFrance
[^]Re: Faut pas exagerer...
Excuse-moi pour le message précédent, je vais la refaire plus calme :
La volonté des développeurs du noyau n'est pas de "fermer" son développement en préférant intégrer les drivers dans la branche principale, mais de prévenir les développeurs externes qu'ils vont devoir s'adapter régulièrement à des petits changements s'ils décident de rester en dehors. Comme ça, ils sont prévenus et n'ont pas à gueuler après, que c'est comme ça que ça se passe quand on fait du dev sur le kernel. Tu va me dire que ça donne le même résultat au final : soit on se fait intégrer upstream, soit on est condamné à rester à la bourre; mais sinon, ce serait le kernel qui serait tout le temps à la bourre.
Là, tu demandes à redéfinir les bases de notre discussion : jusqu'à maintenant, l'interface des drivers n'est pas une interface utilisateur car justement tout se passe en espace kernel, pas utilisateur. Mais donc ce que tu proposes aujourd'hui c'est de standardiser l'interface driver ? Ca demande un autre débat ...
Quel rapport entre maintenir une API stable et la qualité du code ? Linux est très bien codé même si son API est changeante.
D'un côté tu reproches l'API trop changeante, et après tu souhaites une réécriture complète (en parallèle avec l'ancienne, je suppose) ? Le changement sera d'autant plus grand ! Des changements petit à petit ça permet justement de pas trop perdre de drivers d'un coup, de faire la transition "doucement" (même si ça casse à chaque fois, les modifications sont mineures). Arriver à une bonne API du premier coup est quasi impossible, c'est pour ça que le code n'est jamais vraiment réécrit "from scratch" quand on propose une nouvelle API. Et ce n'est pas parce que ce n'est pas refait complètement que c'est bancal ! Franchement, regarde les sources du noyau, ya des fichiers qui ont encore l'entête de linux avant la 1.0, et pourtant ils sont aujourd'hui, après modifications successives, très bien intégrés à l'ensemble.
Bon, depuis le début, tu parles de changements incessants : aurais-tu un exemple ? (c'est pas pour te faire chier à montrer que j'ai raison ou que t'en trouves pas, c'est vraiment pour étudier le problème plus concrètement) Des changements d'ABI incessants, peut-être, et c'est normal, pour l'API par contre ... à moins que tu ne parles d'une section encore expérimentale ou en cours de développement ?
Pour ton problème spécifique, ça me paraît dommage en effet, c'est peut-être le manque de détermination du dev qui a fait que peu de personnes se sont intéressées à l'intégration... alors oui c'est encore un autre problème, surtout quand on est sur un problème qui concerne peu de personnes (selon moi, je ne connais pas vraiment grand monde qui a une AIW), il faut arriver à convaincre les devs upstream que son problème est important. C'est toujours pareil, on est pas dans une entreprise, on est dans un projet communautaire ... Bon, ça doit pas devenir une excuse, effectivement pour ce cas là il y a effectivement un problème, mais ce n'est pas un problème d'API selon moi (sinon je veux bien quelques liens pour mieux comprendre).
Pour le coup des devs qui changent l'API rien que pour faire chier les devs proprio, je te laisse dans ta parano, ce n'est pas du tout ce que j'ai dit.
Je comprend ce que tu veux dire par là, mais je ne serais pas aussi extrême : oui ça prend pas mal de temps de s'adapter, mais ce n'est pas du dev "fermé".
Alors moi aussi je vais dire que tu fais exprès de ne pas comprendre : POSIX désigne une interface utilisateur, ce qui n'a rien à voir avec une interface driver. On aura toujours une API permettant d'ouvrir un fichier avec une fonction, de lire tant d'octets avec une autre, etc ... Par contre, pour le matériel, les nouveaux bus, les nouvelles technologies, etc ... arrivent régulièrement, et il faut s'adapter. Et même les anciennes suivent le pas.
Le problème, à mon avis, en tant que simple utilisateur, c'est que tu n'as pas à t'occuper de ces problèmes (je n'ai pas dit que tu n'avais pas le droit de donner ton avis par contre, soyons clairs). Cela devrait être réglé par les devs. Je trouve ça dommage par contre si certains utilisent leur communauté d'utilisateur comme moyen de chantage sur d'autres devs.
J'ai cité l'intégralité de ton commentaire, en analysant phrase par phrase, et en m'efforçant de comprendre quand ce n'était pas des critiques lancées gratuitement en l'air.
Oui, dans l'idéal, ce serait comme ça qu'il faudrait faire. Mais trouve moi quelqu'un qui arrive du premier coup à rassembler toutes ces qualités dans son code. Il n'existe aujourd'hui aucun OS capable de cela sans un minimum de changement de code et de cassage d'API.
Je pense que tout le problème, c'est de décider entre avoir un truc très stable mais sur lequel il faudra bidouiller au cas où on a pas visé juste du premier coup, ou alors faire un truc qui évolue tout le temps, mais qui casse régulièrements les APIs. La solution choisie pour linux est la 2e, et la philosophie du développement kernel, ça a toujours été d'effectuer les changements petit à petit, sans trop gros accoups. Au final, cela permet d'évoluer plus vite, et la modularisation arrive petit à petit; un jour, on verra peut-être une interface stable aux drivers, quand le kernel aura bien été séparé et "standardisé". Par exemple, la possibilité d'utiliser une machine sans MMU (changement assez profond, quand même), n'a été intégrée qu'au 2.6, alors qu'il existait des patches depuis quelques temps pour le 2.4, mais il a fallu la volonté des devs et leur persévérance pour changer petit à petit le code du noyau, jusqu'à être intégrés upstream.
[^]Re: Faut pas exagerer...
Excuse-moi pour le message précédent, je vais la refaire plus calme :
Merci, c'est beaucoup plus intéressant comme ca en plus ;)
Tu va me dire que ça donne le même résultat au final : soit on se fait intégrer upstream, soit on est condamné à rester à la bourre; mais sinon, ce serait le kernel qui serait tout le temps à la bourre.
Toutafé :)
jusqu'à maintenant, l'interface des drivers n'est pas une interface utilisateur car justement tout se passe en espace kernel, pas utilisateur.
Je n'employais pas le terme utilisateur au sens séparation espace noyau/espace utilisateur, mais au sens utilisation : le kernel offre des services et des points d'entrée pour s'interfacer avec lui. Pour moi les drivers sont un moyen d'utiliser le kernel (et réciproquement) au même titre que POSIX (même si c'est pas du tout le même cadre d'utilisation), les drivers ne doivent pas être "fagocités" par le kernel.
Quel rapport entre maintenir une API stable et la qualité du code ? Linux est très bien codé même si son API est changeante.
La stabilité de l'API constitue également une qualité. Il y a pleins de choses qui font qu'une brique logicielle est de qualité : qualité du code, qualité de la documentation, qualité de la conception, etc. J'ai essayé d'expliquer que des API non stables peut être véritablement handicapant, que ce n'est pas une simple question de compatibilité avec le proprio, que c'est un problème de qualité plus général.
D'un côté tu reproches l'API trop changeante, et après tu souhaites une réécriture complète (en parallèle avec l'ancienne, je suppose) ?
Oui, en parrallèle. On met en place un groupe "d'architecte" qui concoivent une API pensée avec les technos d'aujourd'hui et celle de demain, on fait un truc "propre" avec une certaine durée de vie. Et surtout on s'arrange pour que ca soit facile à "échanger" contre un nouvel API dans le futur, car c'est évident que le boulot devra être refait dans plusieurs mois/années. Si c'est bien foutu, on pourra créer une nouvelle version de l'API plus tard, migrer ceux qui sont important, et garder la compatibilité avec l'ancien. Un peu comme de nombreuses bibliothèques au niveau applicatif. Ca marche très bien, on conserve la compatibilité avec les "vieux" trucs qui personne ne veut plus toucher (le plus souvent "parceque ca marche") et de l'autre on propose du neuf.
Bon, depuis le début, tu parles de changements incessants : aurais-tu un exemple ?
Fut un temps ma clé USB était reconnue. Puis pouf plus reconnue. 1 an après re-reconnue. Relou. Pareil pour ma carte son, fut une époque où la sortie numérique fonctionnait, plus maintenant. Tu me diras sur ce coup je suis pas sûr, ca vient peut être du serveur de son qui a changé, je sais pas trop à quel niveau ca se passe ca.
.. alors oui c'est encore un autre problème, surtout quand on est sur un problème qui concerne peu de personnes
C'est pour ca que dire "on a les sources, c'est pas proprio, ca va évoluer avec le noyau", c'est illusoire. C'est pareil dans le monde proprio, les vieux trucs qui deviennent "anonymes" ne sont plus maintenu par manque d'intérêt de la part des dev. Et c'est pour ca que j'aimerai bien que les API restent stables pour que je puisse garder mon vieux driver-qui-marchait plutôt que de le voir évoluer vers le néant.
oui ça prend pas mal de temps de s'adapter, mais ce n'est pas du dev "fermé".
J'ai bien entendu forcé le trait. Mais l'idée est là : les dev du noyau veulent fagociter un maximum de chose, ils promettent le support du vieux matos mais le résultat n'est pas forcement là, et ca se comprend aisement. Et je suis près à parier que plus la base de driver va grossir, et plus on aura de problèmes.
Le problème, à mon avis, en tant que simple utilisateur, c'est que tu n'as pas à t'occuper de ces problèmes
Toutafé. Et moi en tant qu'utilisateur je constate parfois les "dégâts". Et j'ai la chance en tant que développeur de comprendre le contexte et le pourquoi du problème, et c'est pour ca que je gueule :)
Par contre, pour le matériel, les nouveaux bus, les nouvelles technologies, etc ... arrivent régulièrement, et il faut s'adapter.
Toutafé. Mais moi je dis que y'a d'autres manière de "s'adapter" à mon sens.
Sinon je plussois toute la fin de ton commentaire ;)
Moi ce que je trouve dommage c'est qu'un des problèmes majeurs de Linux est le support du matos, à cause du manque de disponibilité de doc de la part des constructeurs. J'ai l'impression qu'on ne fait rien pour mettre en évidence les avantages de drivers libres, à savoir la pérennité dans le temps, la réutilisation, toussa, et c'est bien dommage.
Pfff, vivement le Hurd ;)
MonoFrance
[^]Re: Faut pas exagerer...
J'ai l'impression qu'on ne fait rien pour mettre en évidence les avantages de drivers libres, à savoir la pérennité dans le temps, la réutilisation, toussa, et c'est bien dommage.
que manque-t-il comme lien explicatif sur cette page :
http://wiki.eagle-usb.org/wakka.php?wiki=CommunicationLibre
(tu noteras notamment la FAQ constructeur + les formations au dév kernel, mais j'ai essayé de retrouver les liens utiles pour avoir tout le contexte)
[^]Re: Faut pas exagerer...
> Mouarf, arrête de parler du problème du proprio. Enlève du sujet le proprio tu veux bien. Moi tu vois lors de l'intégration du pilote libre Gatos dans X.org (gestion des tuner et I/O video des cartes Radeon AIW), j'ai tout simplement vu disparaître un grand nombre de fonctionnalité de ma carte graphique.
Tu peux préciser ?
Et puis si tu n'est pas content , reste sous Windows ! Ha, 2s... on me souffle dans l'oreille que ta Radeon AIW n'est plus supporté par ATI sous Windows et que tu peux te brosser pour la faire tourner sous Vista et qu'au final il n'y a plus que Linux pour être capable de la faire fonctionner !
[^]Re: Faut pas exagerer...
Tu peux préciser ?
Ben concrêtement avant j'installait le driver Gatos, et j'avais la possibilité d'utiliser la sortie TV de la carte par exemple. Depuis "l'intégration" à X.org, marche plus. Et évidemment Gatos n'est plus maintenu en externe.
Et puis si tu n'est pas content , reste sous Windows !
Déjà faudrait que j'y sois :) Non, justement je préfèrerai profiter de ce qu'apporte les LL : à savoir des drivers qui peuvent être pérennes dans le temps. Mais visiblement le kernel en décide autrement.
MonoFrance
[^]Re: Faut pas exagerer...
Je ne pense pas qu'il soit question d'une conspiration, mais plutot d'un constat. Si on lit ça http://lxr.linux.no/source/Documentation/stable_api_nonsense(...) on peut en extraire : "Simple, get your kernel driver into the main kernel tree". Pour moi ça veut quand meme dire que torvald, il préfére que l'on mette son code dans la branche principale. Mais bien entendu je trouve ça trés bien qu'on puisse inclure son driver dans la branche principale.
Peut être que la norme POSIX a été faite pour qu'un programme codé pour cette norme fonctionne partout et toujours où celle ci existe ? Et je pense que c'était ça le fondement de son propos. Faire qu'un driver un fois codé pour linux fonctionne le plus longtemps possible.
Bah si elles sont si pourries ces API pourquoi ils les ont mises dans le kernel ? Et tu entends quoi par des API stables ?
Pour moi un des gros problémes des API qui bougent, c'est simplement le fait que quelques fois tu es un gros noobs et tu achétes du matériel compatible avec un driver libre. Ce driver se trouve dans la branche X du noyau et toi t'as la version X-2 sur ton ordi. Comment tu fais ?
- Tu upgrades ta distro ? : T'as pas forcément envie, ça marche bien et t'as pas envie de tout casser.
- Recompiler ton noyau, faire un package , toussa. : Pas trés simple et ça fou les boules de recompiler son noyau.
- Récupérer les sources du module nécessaire sur le site du projet la version pour ton noyau X-2 : Pas trés simple et en plus on a pas forcément les derniers bugfix ce qui peut se révéler assez génant.
PS : T'énerve pas, c'est pas la fin du monde. On parle juste d'un programme informatique.
[^]Re: Faut pas exagerer...
Oui, je suis d'accord que c'est une forte incitation à mettre son code dans la branche principale. Mais je réagissais au fait que TImaniac dise que Linus voudrais "tout maîtriser" et "forcer les gens", ce qui est un tout petit peu exagéré...
Oui, mais comme j'ai précisé plus haut, l'interface POSIX est une interface utilisateur et plus haut niveau. Les interfaces driver sont assez différentes de cela, et à mon avis c'est difficilement transposable.
OK j'exagère en disant pourri, mais des fois les devs se rendent compte que les choix qu'ils ont fait à une époque n'étaient pas les bons, et qu'il faudrait changer d'API. Et par API stable, j'entend .... qu'elles change pas du tout ?
Oui c'est vrai que c'est assez embêtant, mais c'est souvent dû au fait que les drivers arrivent beaucoup plus tard que la sortie sur le marché du matos, car les devs n'ont soit pas les docs (ou pas assez tôt), et alors ils sont obligés de faire du reverse engineering, et ça prend du temps.
Oui, faire des API stables et s'y tenir c'est difficile et ça prend du temps, chose que n'a pas toujours la communauté. Si les constructeurs matériel jouaient plus le jeu du libre, je pense qu'on aurait pas ce genre de problème et qu'on pourrait avoir des APIs changeantes sans problème.
Oui désolé, merci d'avoir calmé le jeu !
[^]Re: Faut pas exagerer...
Si tu t'en branles qu'il évolue, pourquoi le mets-tu à jour ??? Le fait que les pilotes soient cassés toutes les 8 semaines ne concerne que les gens qui mettent à jour leur kernel toutes les 8 semaines. Si un rtyhme de une fois tous les 7 ans te satisfait pleinement, rien ne t'empêche d'attendre 7 ans.
Y a t il qqchose que je n'ai pas compris ?
[^]Re: Faut pas exagerer...
On peut avoir envie de profiter des évolutions sans avoir envie de subir également des régressions.
MonoFrance
[^]Re: Faut pas exagerer...
Bonne chance mon gars pour backporter les màj de secu ou de bug du kernel. À moins d'utiliser un truc comme une RHEL mais là faut accepter d'avoir le même desktop gnome (mais surtout GTK) ad vitam æternam.
[^]Re: Faut pas exagerer...
>mais là faut accepter d'avoir le même desktop gnome (mais surtout GTK) ad vitam æternam.
En meme temps tu peux mettre à jour gnome et non le kernel.
[^]Re: Faut pas exagerer...
Perso, moi qui suis du grand public simplement amateur de logiciel libre, oui, ça m'a dérangé, de constater le comportement plusieurs fois différent de mes clés USB, par exemple.
Ça a même dérangé deux développeurs de Mandriva, qui écrivaient récemment sur leur blog leur colère de voir le noyau toujours changeant et aux fonctions jamais maintenues plus d'une semaine, et qui accusaient les développeurs du noyau d'être des idiots, de ce point de vue-là seulement j'imagine ! ( ici, http://distrowatch.com/weekly.php?issue=20061002#news , descendre vers la 2ème actu).
Si des profils d'utilisateurs aussi différents en souffrent, c'est qu'il y a quand même un problème, non ?
[^]Re: Faut pas exagerer...
Pourquoi une note négative sur le commentaire de PBPG ? C'est troll vélu ? Ca dérange un commentaire comme ça ?
(J'ai pas regardé en détail, mais d'après ce que j'ai pu voir, il y a un bon paquet de doc sur les API windows, c'est vrai les changelogs j'ai pas trop regardé)
[^]Re: Faut pas exagerer...
Effectivement, j'ai l'impression que pour certains, des qu'ils voient "PBPG", ils cliquent immediatement sur "inutile", sans reflechir...
Les boutons pour evaluer les commentaires devraient servir a faire disparaitre les commentaires hors sujet/deplaces, pas a indiquer si l'on est 100% d'accord avec ce qui est dit!
Et puis il faudrait peut etre se rendre compte que l'attitude consistant a systematiquement refuser toute critique du libre n'est PAS celle qui va permettre de faire avancer le libre! Si sur la LKML tout le monde passait son temps a uniquement parler de ce qui va bien en refusant ce qui ne marche pas bien, nous en serions toujours a un clone de Minix...
Mathias
[^]Re: Faut pas exagerer...
Son message, sans aucun lien, n'a aucun intérêt. On est sensé savoir de quoi il parle? C'est quoi les nouveautés kernel entre les SP? Y a de la transparence dans le développement aussi? Ben s'il le dit...
Faudrait voir a pas tomber dans le travers inverse et applaudir tout ce que dit le camps d'en face. pbpg dit des truc intéressants il est pertinenté, il fait un post de merde il se mange un -10. Voila.
Aprés, on pourrait peut-être lui envoyer un gateau pour la release de Vista. :p
[+] [^]Re: Faut pas exagerer...
Effectivement, j'ai l'impression que pour certains, des qu'ils voient "PBPG", ils cliquent immediatement sur "inutile", sans reflechir...
Oui, c'est mon cas :-)
Les boutons pour evaluer les commentaires devraient servir a faire disparaitre les commentaires hors sujet/deplaces, pas a indiquer si l'on est 100% d'accord avec ce qui est dit!
Moi, de toutes façons, je lis souvent les post fermés justement pour savoir pourquoi.
Et accessoirement, je pense aussi que les évolutions des deux noyaux sont difficilement comparables si on fait une comptabilité bête et méchante des lignes de codes, patchs et services packs comme le ferait un manager qui comptabiliserait les lignes de code pour en faire un indice de productivité.
[+] [^]Re: Faut pas exagerer...
Effectivement, j'ai l'impression que pour certains, des qu'ils voient "PBPG", ils cliquent immediatement sur "inutile", sans reflechir...
Et alors ? C'est une attitude saine et rafraîchissante, mon enfant, qui ne peut que t'amener sur le droit sentier de la Justice et de la Vérité.
Je sais que vous êtes tous d'accord avec moi lorsque j'affirme pBpG est un parasite a exterminer le plus rapidement possible et avec le moins de dégâts collatéraux. Seul la masse pronétaire possède la puissance suffisante pour faire plier cet être stupide, borné et maiprisant, presque indigne de nos attentions et assurément la pire loque humaine que le bon Dieu n'ai jamais osé crée.
[^]Re: Faut pas exagerer...
Quand au processus soi-disant ferme
Tu bosses pour Microsoft ou quoi? Parceque pour le commun des mortels (voir meme les informaticiens) les informations sur le developpement du kernel XP/Vista ou sur tout produit estampille Microsoft sont totalement opaque.
[^]Re: Faut pas exagerer...
Tu veux un exemple d'ouverture ? le blog de Raymond Chen, qui explique toutes les raisons pour laquelle si et ça se comporte pas toujours comme prévu pour des raisons de backward compatibility.
http://blogs.msdn.com/oldnewthing/
Un de mes exemples favoris de ce blog :
http://blogs.msdn.com/oldnewthing/archive/2005/01/18/355177.(...)
Microsoft prends la stabilité des API et la compatibilité avec les vieilles applis très à coeur.
[^]Re: Faut pas exagerer...
Microsoft prends la stabilité des API et la compatibilité avec les vieilles applis très à coeur.
C'est pas parceque tu le repetes que ca va devenir vrai. J'ai un scanner qui a pas supporte le passage a XP (il se comporte a merveille sous linux malgre les API non stable des drivers).
Tu critiques que l'API des linux bougent mais ca gene qui? Uniquement les trucs dont les sources ne sont pas dispos et donc a l'ouest de la philosophie linux donc franchement pas du tout important.
[^]Re: Faut pas exagerer...