Journal : Marre de l'intégrisme chez les libristes !!!
Posté par Samuel Pajilewski () le 25 septembre 2007
0
Bonjour,Je tiens par le biais de ce journal montrer mon mécontentement concernant l'attitude belliqueuse de certaines personnes sur ce site concernant tout ce qui n'est pas OpenSource !
En lisant le journal sur Creative (et le pilote pour sa carte Xfi), j'ai analysé les commentaires, et je trouve cela aberrant.
Grosso modo voila l'argumentation :
-> C'est des pilotes binaires donc c'est nul
-> Faut interdire les pilotes binaires
-> Faut obliger les entreprises à donner leurs spécifications
Je trouve cette attitude lamentable : ce qui me plait en Linux, c'est le choix, sa diversité, la liberte de choisir ce que l'on veut.
Si un constructeur décide de supporter Linux en fournissant des drivers non libres pour son matériel, libre à lui ! Pourquoi l'obliger à donner les spécifications ? Cela serait contraire au principe des libertés fondamentales.
Imaginez un jour qu'un parti politique (au hasard le Parti Communiste) crie a coeur joie "plus de liberté, la liberté au peuple !"
OK, un jour il arrive au pouvoir et là hop :
-> Plus le droit de devnir propriétaire : tout appartient à l'état
-> Plus le droit d'être actionnaire
-> Interdiction du libéralisme
-> Interdiction des autres partis...
Au final : plus de liberté !
C'est ce que vous voulez dans Linux ?
Moi je crois que Linux n'est plus l'OS du début des années 90s, où ce furent des étudiants qui conçurent un OS pour étudiants.
Maintenant Linux signifie Liberté, choix, mais aussi Business et rentabilité.
Alors un peu d'ouverture d'esprit messieurs ! Si vous crachez sur tout ce qui est proprio, alors tant mieux, mais laissez les autres se faire une propre opinion du sujet.
J'espère pour vous que vous ne roulez pas en voiture (monopole pétrolier, spécifications pas toujours libres...), que vous n'avez pas de télévisions (les chaînes ne sont pas libres) et que vous vous lavez dans les rivières (l'eau n'est pas libre non plus dans les robinets)
> Lire le journal (65 commentaires, moyenne: 3,1).
Vous avez demandé le commentaire #870067.
Run by 
Cette page a été générée par Templeet en 0.0893s (dont 0.0096 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Confiance
La raison cohérente pour laquelle on peut avancer qu'un pilote binaire est une mauvaise chose, c'est la confiance. Faire une confiance aveugle à une entité dont le seul intérêt est de sous tirer de l'argent n'est pas une attitude prudente.
Voila, sinon je vois pas trop à quoi rime ton discours, personne t'empêche d'utiliser ce driver pour autant que je sache, pas plus que de te faire une opinion sur celui-ci par toi-même.
À t'entendre il ne faudrait faire usage de sa liberté d'expression que pour tenir des propos qui te conforte dans tes propres hypothèses.
Le wiki de l'association culture libre : collection d'œuvres sous licence art libre.
[^]Confiance et pérénité
Un pilote (binaire ou non) s'execute dans l'espace kernel et a donc acces a tout (y compris memoire utilisateur,donnée personnelle et mots de passe que tu pourrais taper au clavier).La confiance dans le fournisseur de ce pilotes est donc necessaire.
En second lieu un pilote binaire n'est pas evolutif,plusieurs probleme peuvent se produirent :
-si tu change de kernel pour une meuilleur gestion du SATA (par exemple) ton pilote binaire ne voudra plus se charger
-si tu arrive a le charger une modif quelqu'onque de l'interface du kernel pourrait faire qu'il plantera ton systeme (plus ou moin aleatoirement)
-si tu change d'architecture proc (32bit/64bit) un pilote binaire ne marche pas non plus (ici par exemple creative ne fourni qu'un pilote 64bits et pas de 32bits)
-si demain un kernel 2.7 voit le jour tous les drivers binaires devront attendre le bon vouloir du fabricant pour evoluer, et le pire c'est que sous windows ces memes fabricant ne propose pas de drivers Vista pour du materiel qui as a peine 2 ou trois ans, les gens sont obligés de changer du materiel fonctionnel contre un autre.
(Avec un driver open source, la source ne se compilerait plus, si des modifs devait etre faites pour le passage du 32 au 64 elle pourrait ce faire, le support d'un driver open source et faisable, binaire non).
La liste est longue je ne site que quelques exemples.
En conclusion ,non le driver binaire ne sont pas une bonne choses.D'un autre coté l'approche de nvidia est déja plus intelligente, le middleware est coupé en deux, la partie driver est open source, la partie library d'utilisation est closed-binaire.
Bon le driver open source est en faite un gros coup d'ouvre boite dans le kernel mais l'approche et la réalisation sont deux choses distinctes.
Merde, ca fait trois fois que je le coupe il est toujours trop court!
-(un stagiaire hardware qui devait connaitre le grand pere de Sylvain Sauvage ;-) )-
[^]Re: Confiance et pérénité
Un pilote (binaire ou non) s'execute dans l'espace kernel et a donc acces a tout [..] La confiance dans le fournisseur de ce pilotes est donc necessaire.
Kernel mal conçu. Beaucoup de pilotes n'ont aucun intérêt à tourner avec les privilèges du kernel et pourrait très bien fonctionner en mode utilisateur. Bref, le vrai problème est ailleur pour ce qui est de la "confiance". Et c'est valable également pour un driver Open-source, on peut faire confiance au fait qu'il ne contient pas de code malicieux, mais on est jamais à l'abris d'une erreur de programmation qui fait tout péter.
si tu change de kernel pour une meuilleur gestion du SATA (par exemple) ton pilote binaire ne voudra plus se charger
Là encore, le problème vient d'une absence de stabilité des API du kernel. Le problème est là encore une mauvaise architecture des interfaces du kernel.
le pire c'est que sous windows ces memes fabricant ne propose pas de drivers Vista pour du materiel qui as a peine 2 ou trois ans, les gens sont obligés de changer du materiel fonctionnel contre un autre.
Même si ce n'est pas toujours vrai, beaucoup de drivers binaires pour Windows XP (voir Win2000) fonctionne toujours sous Vista. Signe qu'il est possible d'avoir une certaine pereinité dans le temps, même entre 2 versions majeures d'un OS.
(Avec un driver open source, la source ne se compilerait plus, si des modifs devait etre faites pour le passage du 32 au 64 elle pourrait ce faire, le support d'un driver open source et faisable, binaire non).
Dans la vraie vie, le code source n'est pas la solution miracle : si le matos n'est pas beaucoup utilisé, personne n'ira maintenir le driver. J'en ai fait l'amer expérience sous Linux avec les drivers Gatos pour ma radeon AIW (pas du matos confidentiel hein), qui reviennent castrés dans le dernier XOrg sans acquisition video. Des sources ne servent à rien pour l'utilisateur lambda qui se trouve seul face à son problème.
S'il y avait un minimum de péreinité des interfaces binaires, on aurait moins de problèmes.
Les sources assurent une meilleure péreinité, une meilleure portabilité (32/64 bits par exemple), mais ca n'est pas non plus une garantie qui remplace une stabilité des API. Parfois c'est une simple illusion.
Plutôt que de s'amuser à maintenir des milliers de drivers dans un même bouzin (pas le choix, c'est monolithique et les interfaces bougent en permanence), ils feraient mieux de s'atteler à stabiliser les API, proposer des nouvelles API et continuer à supporter binairement les anciennes. C'est du boulot, mais c'est sûrement pas pire que maintenir des milliers de drivers. Ca laisserait les gens les plus compétents (souvent les constructeurs) gérer le cycle de vie de leurs drivers, qui ne devrait pas être imposer selon les bons vouloir de Linus & Co.
Si en plus ca pouvait faire réfléchir à l'architecture du kernel (stabilité des API, privilèges du code exécuté)
Et oui, ca laisserait la porte ouverte aux pilotes binaires, mais c'est quoi le problème ? Au pire on a du matos supplémentaire qui fonctionne sous Linux sans alternative libre, au mieux ca fait double emploi avec un driver libre. C'est où le problème ?
Enfin si le kernel ne veut pas bouger, heuresement des acteurs plus pragmatiques commencent à se bouger le cul (style Dell : http://linux.dell.com/projects.shtml ) ou des petits projets comme FUSE ( http://fuse.sourceforge.net/ ). Dommage d'en arriver à des abérations où on est obligé de créer des couches de glue supplémentaire pour palier des manques de conception sous-jacent.
Ah oui dernier point : stabiliser les API favoriserait l'apparition de drivers alternatifs maintenus par d'autres personnes que les developpeurs du kernel, voir des kernels alternatifs qui profiterait de l'API stable pour supporter un grand nombre de drivers.
MonoFrance
[^]Re: Confiance et pérénité
Le respecte de la licence du noyau ?
Pour rappel, quelque soit la forme de l'API du noyau, le pilote est un travail dérivé du noyau, donc doit être sous GPL.
[^]Re: Confiance et pérénité
si tu change de kernel pour une meuilleur gestion du SATA (par exemple) ton pilote binaire ne voudra plus se charger
Là encore, le problème vient d'une absence de stabilité des API du kernel. Le problème est là encore une mauvaise architecture des interfaces du kernel.
La stabilite des API, c'est une catastrophe. Imagine un OS fige dans ses API depuis des decennies. Le nombre de wrapper, la difficulte de maintenir aux bugs pres des interfaces dans le temps. C'est juste une grosse connerie. Il faut pouvoir tout casse pour avoir de meilleur perf, fixer des bugs, factoriser du code et j'en passe.
le pire c'est que sous windows ces memes fabricant ne propose pas de drivers Vista pour du materiel qui as a peine 2 ou trois ans, les gens sont obligés de changer du materiel fonctionnel contre un autre.
Même si ce n'est pas toujours vrai, beaucoup de drivers binaires pour Windows XP (voir Win2000) fonctionne toujours sous Vista. Signe qu'il est possible d'avoir une certaine pereinité dans le temps, même entre 2 versions majeures d'un OS.
Et tu n'imagines pas la difficulte que c'est de maintenir tout ca, de devoir avoir deux interfaces de drivers dans le noyau. La stabilite et l'evolutivite de l'ensemble en prend forcement un coup. Cela explique bien a mon avis le temps de developpement qu'a pris Vista pour un gain final pas enorme.
Ca laisserait les gens les plus compétents (souvent les constructeurs) gérer le cycle de vie de leurs drivers, qui ne devrait pas être imposer selon les bons vouloir de Linus & Co.
Euh, tu as deja eu acces a du code de constructeurs ??? Parce que c'est bien la derniere chose que tu ecrirais si c'etait le cas. Dailleur la principal raison que ces gens devrait avoir de garder leur code proprietaire, c'est parce qu'ils devraient avoir honte d'ecrire de tel infamie. Serieusement, les drivers du noyau linux sont souvent mieux maintenu, suivent mieux les evolutions du noyau que ceux des constructeurs et ca permet aux utilisateurs de ne pas a avoir de souci de driver.
Je te rappelle quand meme que sous Windows qui a l'air d'etre ta reference, tu passes un temps dingue a devoir trouver tous les drivers qui vont bien. Alors que sur mon linux, je n'ai jamais ce probleme (soit ca marche, soit ca marche pas, dans la majorite des cas).
[^]Re: Confiance et pérénité
La stabilite des API, c'est une catastrophe. Imagine un OS fige dans ses API depuis des decennies.
POSIX, une catastrophe ? :-)
(Note aux nerveux: c'est du second degres, je sais qu'on parle d'API kernel).
Sinon, entre "des decennies" et "chaque version majeure", il y a une difference. Pourquoi faut-il toujours en rajouter ?
[^]Re: Confiance et pérénité
La stabilite des API, c'est une catastrophe. Imagine un OS fige dans ses API depuis des decennies.
Qui te parle de décennies ? Quelques années ca serait déjà pas mal (genre 3-5 ans). Stable veut pas dire "figés". Je demande juste une certaine "durée de vie".
Windows et Mac OS ont des API stables. Gnome et KDE ont des API stables. Y'a que le kernel qui a cette abération.
Et tu n'imagines pas la difficulte que c'est de maintenir tout ca, de devoir avoir deux interfaces de drivers dans le noyau.
Bof, j'imagine très bien, c'est pas la mort. Pas pire que maintenir 100000 drivers quand les API changent en tout cas. Sous Windows ils le font, c'est que c'est faisable. Si le but est de faciliter les utilisateurs (qu'ils soient end-users ou développeurs de driver). De plus si c'est pas le kernel qui le fait, c'est d'autres projets qui vont le faire, chacun va réinventer la roue (nvidia, Dell, etc.).
Cela explique bien a mon avis le temps de developpement qu'a pris Vista pour un gain final pas enorme.
Quand mon driver graphique plante, l'OS le relance. Quand mon driver audio plante, l'OS le relance. Pour moi c'est un gain énorme. Quand un service pack sortira, le kernel sera modifié, je sais que mes drivers marcheront toujours, pas comme sous Linux où je prie systématiquement pour que mon matos fonctionne comme avant.
Euh, tu as deja eu acces a du code de constructeurs ???
Houlà à aucun moment j'ai dis qu'il fallait se contenter des drivers binaires, ne pas réécrire de drivers libres, ne pas faire pression sur les constructeurs pour qu'ils libèrent leurs specs. Au contraire. Mais ca ne doit pas être une excuse pour ne pas offrir tout le confort d'un API stable aux utilisateurs.
Enfin bon c'est le classique débat entre les développeurs qui se focalise sur leur logiciel et les développeurs qui se focalisent sur les utilisateurs de leur logiciel.
Je te rappelle quand meme que sous Windows qui a l'air d'etre ta reference, tu passes un temps dingue a devoir trouver tous les drivers qui vont bien.
Ah bon ? Moi c'est rigolo sous Windows, le driver est toujours sur un CD avec le matos quand l'OS ne le reconnait pas directement (après éventuel téléchargement sur Windows Update sans intervention de ma part). Sous linux, si le matos ne marche pas, ben tant pis pour moi. Au pire je trouve d'obscures documentation qui me disent comment recompiler le noyau pour obtenir telle ou telle fonctionnalité. Yahoo. Chacun son expérience hein.
tout ca pour dire que sous Linux on pourrait faciliter la vie des constructeurs, démocratiser Linux, sachant qu'on pourrait combiner les avantages des OS proprio (à savoir qu'eux n'ont pas le choix de stabiliser leurs API) : API stables, et kernel + drivers libres pour meilleur support péreinité.
Les 2 qualités ne sont pas opposés, et ca serait un sacré atout de Linux face à Windows. Mais non, les développeurs du kernel préfèrent garder la main mise sur les drivers et leur interdire toute vie alternative. Au nom de quoi ? D'un supplément de souplesse dans les API. Mouarf. Elle est où l'API révolutionnaire par rapport à Windows ou Mac OS X qui justifie cette souplesse par rapport à un modèle plus stable ?
MonoFrance
[^]Re: Confiance et pérénité
Windows et Mac OS ont des API stables. Gnome et KDE ont des API stables. Y'a que le kernel qui a cette abération.
Pour Mac OS je n'en sait rien je l'ecarte de ma reponse, pour API Win32 oui c'est stable et tes appli , comme pour linux, marche entre deux version de windows ou deux version de linux kernel.
Par contre ne crois pas que pour les drivers windows rien ne change, prend un disque fournit avec une des tes cartes et regarde, tu trouveras un repertoire 9x,2K,XP et Vista.
Justement, combien de temps apres la sortie de Vista as t'on put trouver des drivers nVidia correct ?
Si nVidia avait jugé que la carte dans ton PC etait trop vielle (plus de 6 mois) pour fonctionner sous Vista tu aurais quoi comme solution a part en acheter une neuve ?
Les 2 qualités ne sont pas opposés, et ca serait un sacré atout de Linux face à Windows. Mais non, les développeurs du kernel préfèrent garder la main mise sur les drivers et leur interdire toute vie alternative
C'est justement tout le contraire, tout les elements disponible pour ré-écrire comme tu le pense les driver ou le kernel sont accessible, ce qui n'est pas le cas avec Windows ou tu ne peut que regarder faire.
La dispo de la source c'est la possibilité d'une alternative, le binaire c'est l'absence de cette alternative.
Merde, ca fait trois fois que je le coupe il est toujours trop court!
-(un stagiaire hardware qui devait connaitre le grand pere de Sylvain Sauvage ;-) )-
[+] [^]Re: Confiance et pérénité
pour API Win32 oui c'est stable et tes appli , comme pour linux, marche entre deux version de windows ou deux version de linux kernel.
Certes, mais on parle des API des drivers là.
Par contre ne crois pas que pour les drivers windows rien ne change, prend un disque fournit avec une des tes cartes et regarde, tu trouveras un repertoire 9x,2K,XP et Vista.
2K,XP en général, c'est le même driver. Ce qui peut changer, c'est qu'avec XP est apparu une certification par Microsoft pour XP (signature numérique du driver), mais globalement tu avais un avertissement mais le driver fonctionnait.
Pour vista, des pilotes XP marchent encore. Ca dépend évidemment du type de matos. Là encore mon but est même pas d'essayer d'avoir quelque chose de stable entre 2 grosses releases, mais déjà entre 2 releases mineures.
Comme tu le fais remarquer, un driver pour Windows n'a pas 36000 dossiers, t'imagines sous Linux si on récapitule tous les drivers nvidia par exemple ?
Justement, combien de temps apres la sortie de Vista as t'on put trouver des drivers nVidia correct ?
Y'avait un driver correct depuis le début. Mais qui ne gérait pas plus de trucs que dans XP, et donc ne gérait pas les nouveautés de Vista qui a introduit un nouveau modèle de driver. Ca n'a pas empêcher Vista de supporter l'ancien modèle (sans les nouveautés évidemment) et nvidia s'est lancé dans le nouveau modèle de driver parcqu'il est certain de sa péreinité (pour quelques années en tout cas).
C'est justement tout le contraire, tout les elements disponible pour ré-écrire comme tu le pense les driver ou le kernel sont accessible, ce qui n'est pas le cas avec Windows ou tu ne peut que regarder faire.
Mais sous Windows tu peux faire un driver libre si tu veux, et le déployer, lui assurer un support, etc. Sous Linux tu sais très bien que c'est quasiment impossible, tu es toujours obligé de courrir après les nouveautés du kernel (même si ton drivers est open-source, ca change rien), la seule solution, c'est d'intégrer ton driver au cycle de vie du driver et de perdre la main dessus.
La dispo de la source c'est la possibilité d'une alternative, le binaire c'est l'absence de cette alternative.
Je suis d'accord. Gardons la dispo des sources, et stabilisons les API qui sera un énorme avantage pour tous, mêmes quand on a les sources.
MonoFrance
[^]Re: Confiance et pérénité
Petite précision quand même dans ce débat qui a déjà eu lieu pas mal de fois : l'API du kernel est assez stable (j'ai pas de durée précise en tête, mais c'est pas tous les ans que chaque partie du noyau change d'API), mais par contre l'_ABI_ elle change effectivement beaucoup puisque qu'à chaque recompilation ça peut casser.
Et c'est le problème avec les pilotes proprios (binaires) : ils dépendent d'une ABI bien précise, et ça ne va pas bien avec le mode d'évolution du kernel.
En tous cas, il y a pas mal de vieux drivers qui sont très peu retouchés car l'API ne change pas si souvent que ça.
[^]Re: Confiance et pérénité
Là encore, le problème vient d'une absence de stabilité des API du kernel. Le problème est là encore une mauvaise architecture des interfaces du kernel.
Si le kernel et ces api evolue c'est parce qu'il doit en etre ainsi, ce qui est stable c'est l'API user space/kernel space.
Si on devait un jour "geler" les interfaces cela serait tout simplement le signe du refus d'évoluer.
Le dernier exemple en date (qui me vient à l'esprit) c'est l'usb, pour l'intégré dans la serie de 2.4 il a fallu 2 ré-écriture (car entre le debut de l'utilisation de l'usb et la finalisation de l'usb 2.0 beaucoup de chose on du etre refaites).
Alors oui, si on avait "stabiliser les interfaces du kernel" on serais sans dout dans la serie 2.2 et on ne pourrait pas utiliser d'usb sous linux serait ce un bien ?.
Même si ce n'est pas toujours vrai, beaucoup de drivers binaires pour Windows XP (voir Win2000) fonctionne toujours sous Vista.
Tu garanti le resultat avec un driver 32 de XP sous Vista 64 bits ? Tu me trouve un driver XP pour mon joystick logitech qui marchait tres bien sous 95 et qui ne marche pas sous XP?
Réponse non, le vendeur de materiel ne porte pas ces pilotes et t'impose de racheter du nouveau materiel pour un nouvel OS, sous Linux il marche tres bien depuis le 2.4 et ma mandrake 8.2 à ma mandriva 2007.1
Signe qu'il est possible d'avoir une certaine pereinité dans le temps, même entre 2 versions majeures d'un OS.
Pour avoir fais des drivers vxd,wdm et kmdf maintenant je te garanti qu'un driver USB unique entre 95,98 et 2000 n'est possible que s'il ne fait rien de bas niveau, ce qui est génant pour un driver.
Dans la vraie vie, le code source n'est pas la solution miracle : si le matos n'est pas beaucoup utilisé, personne n'ira maintenir le driver. J'en ai fait l'amer expérience sous Linux avec les drivers Gatos pour ma radeon AIW (pas du matos confidentiel hein), qui reviennent castrés dans le dernier XOrg sans acquisition video. Des sources ne servent à rien pour l'utilisateur lambda qui se trouve seul face à son problème.
Le code source te garanti que toute les informations necessaire sont disponible pour utiliser le materiel, pas que quelqu'un fera le boulot si personne n'utilise la carte, pas que ce sera gratuit mais si tu decide de payer quelqu'un pour le faire tu as plein de SSLL ou de dev. indépendant qui peuvent faire le boulot.
S'il y avait un minimum de péreinité des interfaces binaires, on aurait moins de problèmes.
Le code irait en grossissant et perdrait en performance à chaque modification, creation d'une nouvelle API si pour toi c'est simplifier les choses...
Ca laisserait les gens les plus compétents (souvent les constructeurs) gérer le cycle de vie de leurs drivers, qui ne devrait pas être imposer selon les bons vouloir de Linus & Co.
La logique d'un constructeurs est de vendre du nouveau materiel, je prefere qu'un Linus tire la barque dans une direction (meme si c'est pas moi qui la choisie ) plutot que de suivre le bon vouloir des constructeurs qui ne ce soucierons que de leurs profits.
Merde, ca fait trois fois que je le coupe il est toujours trop court!
-(un stagiaire hardware qui devait connaitre le grand pere de Sylvain Sauvage ;-) )-
[^]Re: Confiance et pérénité
Si on devait un jour "geler" les interfaces cela serait tout simplement le signe du refus d'évoluer.
Windows fait évoluer ses interfaces, c'est pas pour ca qu'elles ne sont pas un minimum stable.
Tu garanti le resultat avec un driver 32 de XP sous Vista 64 bits ? Tu me trouve un driver XP pour mon joystick logitech qui marchait tres bien sous 95 et qui ne marche pas sous XP?
Est-ce que j'ai dis que c'était toujours le cas ?
Pareil sous Linux : tu prends un drivers de linux 2.2, je te met au défit de le recompiler sur un 2.6 toi même.
Réponse non, le vendeur de materiel ne porte pas ces pilotes et t'impose de racheter du nouveau materiel pour un nouvel OS
Non, car on aura un driver libre. C'est pas parcqu'on autorise les drivers binaire qu'on n'interdit les drivers libres.
Pour avoir fais des drivers vxd,wdm et kmdf maintenant je te garanti qu'un driver USB unique entre 95,98 et 2000
Forcement y'a eu un gros gap entre 95/98 et 2000. J'interdit pas les gros changements, mais pas tout le temps. A chaque grosse version. entre la première version de Win2000 et le dernier service pack il s'est écoulé plusieurs années, et tes pilotes se sont mis à ne plus marcher ?
mais si tu decide de payer quelqu'un pour le faire tu as plein de SSLL ou de dev. indépendant qui peuvent faire le boulot.
On est d'accord, dans la vraie vie de monsieur tout le monde, c'est une illusion. Une pseudo solution.
Le code irait en grossissant et perdrait en performance à chaque modification, creation d'une nouvelle API si pour toi c'est simplifier les choses...
C'est pourtant ce que font tous les gros softs dignes de ce nom qui s'interfacent avec des composants extérieurs. Je dis pas que c'est plus simple. Je dis que c'est penser aux utilisateurs. Si pour toi un soft ne doit pas être conçu pour ses utilisateurs, ca sert à rien qu'on discute.
Là encore, tous tes arguments se basent sur une critique des drivers binaires. Moi je demande une API stable. Rien d'incompatible avec les drivers libres. La compatibilité avec les drivers binaires n'est qu'un avantage supplémentaire.
MonoFrance
[^]Re: Confiance et pérénité
Pareil sous Linux : tu prends un drivers de linux 2.2, je te met au défit de le recompiler sur un 2.6 toi même.
Perdu j'ecris des drivers windows pour mon boulot et des drivers linux pour notre matos pour me faire plaisir.
Non, car on aura un driver libre. C'est pas parcqu'on autorise les drivers binaire qu'on n'interdit les drivers libres.
Si on laisse les constructeurs fournir des drivers binaires leur visions financiere dictera la suite et on aura jamais de pilote libre.
On est d'accord, dans la vraie vie de monsieur tout le monde, c'est une illusion. Une pseudo solution.
A mettre en balance avec l'absence de solution.
C'est pourtant ce que font tous les gros softs dignes de ce nom qui s'interfacent avec des composants extérieurs. Je dis pas que c'est plus simple. Je dis que c'est penser aux utilisateurs.
Et quand c'est vraiment plus gerable, hop une release majeur ou on casse toute la compatibilité ancienne [bin oui comprenez on a rajouté plein de nouvelle fonction qui rende les anciens composants exterieur inutile ou incompatible....], tu veut que l'on parle de l'echange de fichier entre les differentes versions de Word ?
Merde, ca fait trois fois que je le coupe il est toujours trop court!
-(un stagiaire hardware qui devait connaitre le grand pere de Sylvain Sauvage ;-) )-
[+] [^]Re: Confiance et pérénité
Perdu j'ecris des drivers windows pour mon boulot et des drivers linux pour notre matos pour me faire plaisir.
T'es pas le bon exemple, mais prend la plupart des moules qui traîne par ici.
Si on laisse les constructeurs fournir des drivers binaires leur visions financiere dictera la suite et on aura jamais de pilote libre.
Bah je croyais que le modèle du libre était le plus pertinent pour les entreprises sur le long terme ? Faut savoir ! Utilisons les arguments habituels sur les atouts du libre, mais ne leur mettons pas des batons techniques dans les roues, ca ne fait que dégrader l'image du libre et les oportunités qu'ils pourraient y trouver.
Et quand c'est vraiment plus gerable, hop une release majeur ou on casse toute la compatibilité ancienne
Oui, et ? C'est du grand classique : t'as les API officielles, les API legacy/deprecated mais encore fonctionnels et les trucs plus gérés. C'est toujours mieux que le cycle de vie des API actuels de Linux ou tu passes beaucoup trop rapidement de officiel à unsupported.
tu veut que l'on parle de l'echange de fichier entre les differentes versions de Word ?
C'est un format de données, pas une API. Enfin si tu veux faire un parallèle, toute l'argumentation du libre repose sur la péreinité des données, la normalisation ISO & Co, bref la stabilité du format ODF. T'imagines si à chaque mise à jour mineure d'OpenOffice.org fallait aller modifier à la mano les balises XML du document pour respecter le nouveau schema parcque les développeurs avaient décider qu'il fallait modifier certaines balises pour s'adapter à leurs besoins tous les 4 matins ? (bah oui, t'as les sources, tu peux le faire !)
MonoFrance
[^]Re: Confiance et pérénité
Youpi! Le retour du troll sur les kernels !
Linux n'a jamais été conçus pour être un os d'avant garde, mais pour être fonctionnel et efficace. En ce sens le noyaux respecte son objectif: Linux ca marche. Effectivement sur beaucoup plus de point l'architecture du noyau n'est pas à l'état de l'art mais c'est pas son but non plus.
La liberté d'un drivers ne veut pas dire que d'autres voudront le maintenir mais que toi tu peux si tu veux quitte a aquérir les connaissances nécessaire ce qui est souvent très difficile je te l'accorde mais au moins c'est possible.
Le desktop n'a pas besoin d'être hyper optimisé mais je lisais récemment un avis d'une boite sur les aspects temps réels de Linux qui disait qu'une latence de 40 mili-secondes pouvait rendre a néant les bénéfices d'un trader. Pour garantir un tel niveau de performance pour une tâche bien spécifique, c'est plus facile quand tu as seul gros machin que tu contrôle de bout en bout. SI les développeur noyau ont besoin de changer une partie d'un composant pour optimiser un autre bout, ils peuvent le faire facilement, ca cassera peut être une API mais ils auront leur optimisation. Toutefois pour ce qui est du Desktop je suis d'accord, une structure plus souple serait préférable.
Puis vu tous les problèmes que pose les drivers binaires, ca donne une motivation de plus au constructeurs de fournir des drivers libres. Plus on tenderat la main aux pilotes binaires et plus il y en aura.
C'est une excellente remarque, vu comment les concepteurs d'OS galerrent pour adapter les drivers d'un système à l'autre ce serait bien d'avoir quelque chose pour faciliter le port de drivers entre système libres. Il y a des trucs qui se font pour utiliser les drivers Linux sur d'autres systèmes, mais j'ai jamais rien vu de vraiment convainquant.
[^]Re: Confiance et pérénité
Même si ce n'est pas toujours vrai, beaucoup de drivers binaires pour Windows XP (voir Win2000) fonctionne toujours sous Vista. Signe qu'il est possible d'avoir une certaine pereinité dans le temps, même entre 2 versions majeures d'un OS.
C'est vrai, de nombreux drivers fonctionnent, c'est bien le cas. Mais quand ça déconne les utilisateurs vont gravement se faire foutre. Va dire ça aux utilisateurs de nforce3 qui est loin d'être vieux.
They subsequently decided to also drop support for nForce3 in late February of 2007 after the release of Vista. NVIDIA is thus the first and only major mainboard chipset manufacturer for at present time that is not supporting a chipset designed for 64-bit processors. The chipset drivers packaged with Windows Vista are usable, but as a result of not being specifically designed for the nForce2 and 3 chipsets, they do not take full advantage of the hardware and lose some functionality. One such problem disables safe removal of IDE and SATA drives.
One issue concerning the lack of natively supported drivers for the nForce3 chipset in Windows Vista has come up with the public release of the operating system and the affordability of dual core systems. In these dual core systems with ATI graphics chipsets above the Radeon 9XXX series, Windows Vista disables the ATI display drivers designed for the operating system and prompt it to default to the PCI-compatible drivers. Windows reports this as Code 43 Error. In PCI-compatible mode, all hardware acceleration is switched off, negatively affecting the performance of the display adapter.
Les drivers proprio sont une nuisance, y'a pas d'autres mots.
[^]Re: Confiance
Bon alors, un pilote binaire, finalement, c'est une mauvaise chose ou c'est éthique ?[1] https://linuxfr.org/comments/868959.html#868959
[ Répondre ] Ce commentaire est-il impertinent ou utile ?
[^]Re: Confiance
Bah les deux : c'est une mauvaise chose et c'est éthique.
Enfin bien sûr ça dépend de ce que tu considère être une bonne chose et de ce que tu considère éthique.
Le wiki de l'association culture libre : collection d'œuvres sous licence art libre.
[+] [^]Re: Confiance
La raison cohérente pour laquelle on peut avancer qu'un pilote binaire est une mauvaise chose, c'est la confiance. Faire une confiance aveugle à une entité dont le seul intérêt est de sous tirer de l'argent n'est pas une attitude prudente.
Voila, sinon je vois pas trop à quoi rime ton discours, personne t'empêche d'utiliser ce driver pour autant que je sache, pas plus que de te faire une opinion sur celui-ci par toi-même.
À t'entendre il ne faudrait faire usage de sa liberté d'expression que pour tenir des propos qui te conforte dans tes propres hypothèses.
Dans ce cas, tu nages dans l'imprudence la plus totale depuis des années... Il y a forcément un moment où tu es bien obligé de faire confiance à quelqu'un pour avoir quelque chose, quelqu'il soit. La plupart des entreprises ne sont motivées que par la possibilité de faire de l'argent et pourtant, tu leur fait bien confiance en leur achetant produits et services et je suis sûr qu'une bonne partie d'entre eux sont vitaux. À ce qu'il me semble, il est rarissime qu'on emploie des dispositifs pour s'assurer que la nourriture n'est pas empoisonnée. Pourtant, tu as bien acheté cette nourriture à un marchand surtout motivé par faire de l'argent et tu auras bien fait une confiance "aveugle" vu que tu n'auras pas vérifié s'il n'y avait rien de toxique dedans...
Et même avec du code ouvert, tu es bien obligé de faire confiance aux développeurs, car, que je sache, tu n'as pas forcément le temps ou les compétences nécessaires pour t'assurer de l'innocuité de tout le code de tous les logiciels que tu utilises.
L'ouverture du code ne peut apporter qu'un peu plus de confiance et ce, uniquement pour les personnes qui sont capables de comprendre le code source. L'utilisateur de base qui constitue 99 % des utilisateurs, lui s'en fout, il continuera à avoir confiance tant que ça marche et il aura bien raison sur le fond.
À mon avis, le seul intérêt à avoir des pilotes ouverts et au code accessible, c'est la maintenabilité et l'éventuelle possibilité de pouvoir faire fonctionner le périphérique plus longtemps que ne pourrait le faire le constructeur. Jusqu'au jour où il n'y a plus de développeur pour la maintenance. Le reste est surtout une affaire de conviction religieuse.
[^]Re: Confiance
La plupart du temps si j'estime qu'une entreprise n'est pas digne de confiance, je vais chercher un service similaire chez une autre entreprise.
Tu plaisantes? Tu crois vraiment qu'y a aucun contrôle sur tout ce qui est allimentaire? Je veux bien que je vérifie pas moi même, mais il existe des organismes dont c'est la seule fonction.
Moi tout seul non c'est sûr. Mais l'avantage du code ouvert c'est que tout le monde peut vérifier une petite partie. Le code d'un spyware dans un logiciel à code ouvert serait plus ou moins vite découvert en fonction du nombre d'utilisateurs/développeurs qui bossent dessus.
Sans parler de conviction religieuse, c'est sûr qu'il y a une grosse part de croyance. Plus exactement, je pense plus probable que microsoft intégre un spyware dans son windows que de trouver un spyware intégré dans un paquet quelconque de debian, même si cette dernière éventualité n'est pas à exclure complètement.
Le wiki de l'association culture libre : collection d'œuvres sous licence art libre.