Cher journal,
En lisant des messages d'un forum d'une distribution dont tout le monde parle alors qu'elle n'a pas réinventé la roue, mais a juste su trouver des noms marrants (pas issu de Toy Story), j'ai eu la pensée suivante : le grand problème de Linux, ce n'est pas le côté user-friendly, les logiciels ou autre. Tous les logiciels disponibles suffisent à la majorité des utilisateurs pour l'usage qu'ils en font, les environnements de bureau sont riches, fournis, beaux. Le problème, ce sont les drivers et les périphériques non reconnus...
Mais pour Windows aussi, c'est pareil. Exemple : j'ai un scanner Agfa. Il ne marche pas sous Windows XP car je n'ai ni le logiciel, ni les drivers : Agfa n'en a pas fait. Alors qu'ils existaient sous Windows 98. Par contre, sous Linux (dans n'importe qu'elle distribution et donc sous ma préférée), le scanner marche et est reconnu.
Il me semble qu'on oublie combien de périphériques ont dû être changés suite au passage sous XP. Il semble qu'on l'est un peu oublié... Maintenant, tout le matériel est compatible XP. Mais dans les mois qui ont suivis la sortie d'XP était-ce le cas... Et avec la sortie de VISTA? D'accord, pour Vista, il faudra changer de PC car les configurations actuelles ne seront pas suffisantes, donc ça ne compte pas.
Il me semble que cet argument de "cet OS n'a pas de driver pour mon matériel" est tout aussi valable pour critiquer l'OS Windows. Pour en revenir à GNU/Linux, il reste à savoir si un driver propriétaire est suffisant, ou s'il faut du tout libre...
En conclusion, les gens qui critiquent Linux voient la paille dans nos yeux, mais pas dans la poutre dans le leurs.
A plus mon journal.
Journal Les drivers : c'est bien là le réel problème
2
août
2006
# C'est faux
Posté par teddyber . Évalué à 1.
http://www.kroah.com/log/linux/ols_2006_keynote.html
[^] # Re: C'est faux
Posté par Zakath (site web personnel) . Évalué à 7.
[^] # Re: C'est faux
Posté par dinomasque . Évalué à 2.
Je trouve qu'installer un périphérique sous Windows est long, compliqué et hasardeux par rapport à Linux ou le plug and play a fait des progrès extraordinaires (pas de drivers de 100Mo à télécharger, pas besoin de rebooter 12 fois sa machine parceque l'installeur du driver est mal fichu, etc.).
Par contre quand on achète un périphérique dans n'importequel magasin, on est sur qu'il marchera sous Windows alors qu'il faut faire très attention sous Linux.
A quand un petit logo "Compatible Linux" sur les boites des périphériques ?
BeOS le faisait il y a 20 ans !
[^] # Re: C'est faux
Posté par Nicolas Bernard (site web personnel) . Évalué à 9.
Et encore! Il y avait un logo linux sur la boite de ma Matrox P650, mais finalement c'est un driver proprio pour x86 only, alors je ne dirais pas que c'est réellement compatible linux.
Moralité, ne pas se fier à ce genre de logo, mais toujours chercher sur le web avant d'acheter.
[^] # Les vendeurs ne connaissent pas Linux
Posté par viking . Évalué à 2.
J'ai acheté récement un lecteur de cartes, de marque Apacer. J'avais été voir sur le site officiel. Et je savais qu'il était compatible. Et puis au final, c'est bien indiqué sur la boite. Mais pour être sur (et pour tester un peu le vendeur) je demande s'il avait des lecteurs compatibles Linux. La réponse du vendeur :
"Ah mais je sais pas monsieur. Ici, on ne vend que du matériel pour PC"
[^] # Re: Les vendeurs ne connaissent pas Linux
Posté par Bruno Adele (site web personnel) . Évalué à 0.
il son meme pas foutu de faire la différence en windows et PC
J'ai eu le meme probleme avec wanadoo, Je disais que j'etais sous linux la dame me retorqué, le support ne fonctionne que sous PC, je lui disais, ben oui justement, j'en ai 1 :)
[^] # Re: C'est faux
Posté par SKBo . Évalué à 2.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: C'est faux
Posté par David Roon . Évalué à 2.
Donc l'important c'est pas combien de matériel il supporte mais s'il supporte mon matériel. Et le problème de Linux est que c'est pas toujours les entreprises qui les développent et donc ça prend du temps.
Bref ne jamais oublier l'objectif: QUE CA MARCHE.
# Commentaire supprimé
Posté par Anonyme . Évalué à 9.
Ce commentaire a été supprimé par l’équipe de modération.
# Mouais
Posté par Rin Jin (site web personnel) . Évalué à 10.
Ce que tu sembles oublier c'est que, comme les bugs et les BSOD à un époque, beaucoup de gens trouve ça normal, conditionné qu'ils sont.
On leur fait croire qu'il est normal que leurs périphériques deviennent obsoléte, ce n'est pas le même OS, leur imprimante a vécu 3 ans? Il est temps de la changer, elle imprime trop lentement, trop ceci, trop cela...
Je me demande quelque fois si cela n'a pas un rapport avec l'absence de drivers libres, ou le manque de spec, de certaines marques de cartes graphiques (NVidia et ATI, pour ne pas les nommer). Si les derniers drivers ne gérent pas les anciennes cartes, il devient indispensable de changer de carte si on change d'OS. Avec des drivers libre, cette obsolésence programée n'est plus possible.
MS va sortir Vista, de nombreux fabriquants en profiteront pour rendre obsoléte leurs matos. MS s'en prendra encore plein les dents ("MS a sorti un OS sous lequel mon scanner ne marche plus, ce sont des incapables"), ce qui n'empéchera pas ces mêmes clients de repasser à la caisse, les fabricants vendront encore des périphériques qui, à la prochaines sortie de windows seront "dépassés".
Tant que les gens trouveront normal que les fabricants se comportent comme des escrocs, il n'y a pas de raison que cela s'arrète.
[^] # Re: Mouais
Posté par kraman . Évalué à 9.
Un pilote windows, c'est un exe avec un installeur, tu double cliques tu fais suivant suivant oui, eventuellement tu rebootes et voila. Le premier connard venu est capable de le faire marcher.
Un pilote linux, soit il est integre au noyau et c'est bonnard, soit il est pas.
Malheureusement des peripheriques tres repandus ne sont pas integres.
Carte 3d, cartes wifi, modems usb (foutu sagem fast 800). Et la, ben bonne chance pour que le premier connard venu arrive a l'installer.
J'ai galerer comme un crevard sur mon fast 800 (offert par free, donc ca devait toucher pas mal de monde) a l'epoque, c'est devenu beaucoup beaucoup plus simple maintenant, mais faut encorey aller a coup de manips specifiques a la distrib (perso j'y allais avec modules-assistant) et surtout savoir ce qu'il se passe derriere pour installer le bousin.
Un maj du kernel casse les pilotes nvidia, le wifi c'est un bordel sans nom.
Ca s'ameliore? Oui, ca s'ameliore. Mais on a toujours un train de retard sur les encules d'en face (sont forts les encules d'en face).
La 3D ca devient presque simple, le wifi aussi apparement (parait il, pas de carte wifi dans mon linux), soit, et je suis le premier a m'en rejouir, mais demain ca sera le nouveau perif' qui vient de sortir.
Bref, faut peut etre aller plus loin que des concours de grosses quequettes en comptant le nombres de peripheriques et voire le reel impact (nombre d'utilisateurs et quantite d'emmerde que ca apporte).
Et la pour le coup, je suis pas sur que linux sorte vainqueur.
On va me repondre "ouais mais nianiania, pilotes libre, proprio tout ca".
Ben ouais, je sais bien, moi je suis capable de comprendre le probleme et d'aller outre, mais je suis pas un pekin moyen, j'suis technicien, curieux, j'aime ca etc. Le mec qui veut un pc juste pour l'utiliser il s'en bellek de ce genre de problemes...
[^] # Re: Mouais
Posté par kraman . Évalué à 4.
ms a sorti 2 os en 6 ans et encore, ca c'est s'ils tiennent le delai du prochain (qui a dit comme debian?)
De notre cote, depuis on s'est prit 2 version majeures du kernel et un nombre incalculables de modif en profondeur, arrivant les unes apres les autres au compte goutte.
Ca pose beaucoup plus de probleme niveau pilotes qu'une migration 98/2000(XP) en 2000(2001) et XP/Vista en 2006(7).
[^] # Re: Mouais
Posté par Rin Jin (site web personnel) . Évalué à 1.
Je compile moi-même mon kernel, plus pour dire "je l'ai fait" et savoir le faire que par nécessité la plupart du temps, mais je ne suis pas, loin s'en faut, ce qu'on pourrait appeler un utilisateur lambda.
La plupart des utilisateurs de Linux, lorsqu'ils n'ont pas envie de se la péter, ne se préoccuperont pas de leur noyau et ne le recompileront donc pas. Or, la plupart des distribs ne s'amusent pas à fournir le dernier noyau dès sa sortie, la version X d'une distrib sera un tout complet comme peut l'être un windows. Si les fabricants qui sortent eux mêmes leurs drivers se focalisaient plus sur l'aspect distribution et proposaient les drivers non plus pour Linux mais pour Red Hat, Mandriva ou Suse, tout en fournissant pour ceux qui le désirent, ou ceux qui n'utilisent pas les distribs cibles, un module plus générique, avec des parties recompilables (voire totalement libre) tel que le fait (faisait?) NVidia, ils s'éviteraient bien des problèmes. Libre alors aux distribs non supporté de fournir eux-même des paquets du drivers.
Bien évidement, si tout les drivers étaient libres, et/ou les spécs données aux clients, on s'éviterait bien des emmerdes.
[^] # Re: Mouais
Posté par kraman . Évalué à 4.
Ca fait beaucoup plus de boulot que de simplement corriger/maintenir un driver 2000/XP sur 6 ans, d'une part.e
D'autre part, pour ce qui est des paquets pour les distribs, c'est juste un probleme de nombre de clients : ils distribuent le paquet, il faut qu'ils le maintiennent, ca veut dire des personnes competentes, du boulot en plus etc. pour un marche qui est petit dans l'absolu, ridiculement miniscule relativement au marche windows et en plus fragmente en plus de sous marches incompatibles entre eux.
Regarde le nombres de distrib a supporter : 2-3 Fedora Core, 2 debian mini, 2 ubuntu, 2-3 suse, 2-3 mandrake, gentoo (je connaispas le cycle de release) ...Rien que la on a 10 produits differents.
Tres sincerment, je comprends le constructeur qui veut pas s'emmerder a debloquer un budget driver equivalent au budget windows pour 0.5% de ses clients.
Meme en etant linuxien convaincu, j'ai ete amene au boulot a packager un produit pour linux. "Ah bah toi tu nous bassines avec ton linux toute la journee, tu vas bien nous faire ca".
Ben je me suis vite rendu a l'evidence : on supporte RH/x86 et demerdez vous pour le reste, j'engage pas ma responsabilite sur 15 distribs (pas le temps de tester). Meme si au fond de moi je suis persuade que ca marchera pareil, je garantit pas si j'ai pas valide.
Ou alors tu me files une demi douzaine de personnes et la facture tu vas la sentir passer.
Un fournisseur pro s'engage aupres de son client, chose que ne fait pas le dev communautaire et ca fait une enooooooorme difference.
Apres la liberation des specs, c'est un autre probleme, c'est effectivement dommage.
C'est tres con, mais c'est une question de masse critique beaucoup plus qu'une question technique. Les fabricants vendent/fournissent ce que veulent les clients, ni plus ni moins.
[^] # Re: Mouais
Posté par Zakath (site web personnel) . Évalué à 4.
Et sinon, gentoo c'est 2 à 3 "releases" par an mais ça ne correspond qu'aux images des LiveCDs pour faire l'install, le reste du temps, tu sync ton arbre portage régulièrement et tu as les nouvelles versions des packages au fur et à mesure.
[^] # Re: Mouais
Posté par kraman . Évalué à 2.
[^] # Re: Mouais
Posté par Manger sur pattes . Évalué à 3.
Pour les modules noyau, il faudrait avoir un standard pour packager les sources et un bel installeur graphique qui va appeler les bonnes commandes et tout ira bien, l'utilisateur aura en plus la joie d'avoir un driver bien optimisé pour son système.
[^] # Re: Mouais
Posté par dinomasque . Évalué à 5.
BeOS le faisait il y a 20 ans !
[^] # Re: Mouais
Posté par wismerhill . Évalué à 2.
Le projet PLF (http://plf.zarb.org/) package plusieurs modules (open-source ou non) de cette façon et ça fonctionne bien.
Je suis récemment passé au drivers proprio nvidia tels qu'ils les packages et c'est du bonheur: lors de l'installation d'un nouveau noyau, il y a un service dkms au démarrage qui se charge de vérifier si tous les modules dont il a connaissance sont compilés pour le noyau en cours, et si non il les recompiles et ils sont tout de suite disponibles.
Bien sur ça ne fonctionne pas pour des modules qui sont nécessaires au lancement de init (contrôleur raid par exemple), ceux-là doivent de toute façon se trouver dans le initrd.
[^] # Re: Mouais
Posté par Médéric RIBREUX (site web personnel) . Évalué à 4.
C'est bizarre, une partie mon job (pas la plus reluisante d'ailleurs) est justement de maintenir un parc d'une centaine de machines sous win2k. Je dois avoir à peu près une dizaine de machines différentes à gérer et bien sûr, d'une version à l'autre, les pilotes sont complètement différents.
Sur la question de l'installeur, je dois dire que plus d'une fois sur deux, ce dernier fonctionne mal et avorte: je suis bon pour extraire les fichiers à la main et à ajouter les pilotes à la mano... c'est top relou. A côté, modules-assistant c'est d'une facilité déconcertante.
Pourtant, mon matériel est loin d'être exotique (c'est de la grande marque). Et je ne vous parle pas de la mise à jour de ces pilotes...
Avec une distribution Linux moderne, j'ai beaucoup moins de problèmes de configuration: 9 fois sur 10, je n'ai rien à ajouter et c'est prêt out-of-the-box. En cas de mise à jour, les outils classiques (apt par exemple) suffisent. Effectivement, les seuls éléments qui posent problème sont les pilotes binaires non libres...
A propos du Wifi: quand je vois la galère que ma femme (et moi) a eu pour configurer sa carte wifi sous WinXP (pourtant c'est du Ralink), modifier un fichier de configuration en mode texte est de la rigolade:
- Le pilote fourni qui déconne plein pot => pas de connexion possible même en clair.
- Après recherche sur le net et un max de versions différentes, on progresse un peu mais comme il faut rebooter à chaque fois, ça prend beaucoup de temps.
- Problèmes de stabilité sur les connexions
- Je ne parle pas de la config WPA2...
- Au final, une connexion complètement pourrie, très instable et qui impose de redémarrer la machine pour refonctionner.
Bref, j'ai dû abandonner au bout de 4H sans rien comprendre: pas de logs (ou si peu) pour voir d'où vient le problème, pas ou peu de docs sur le sujet, rien au niveau de la "communauté"...
Sur la même machine, l'installation d'Ubuntu Breezy suivie de deux commandes (un apt-get) et une modification de fichier de configuration et c'était joué !
[^] # Re: Mouais
Posté par cxente . Évalué à 7.
Le mec qui veut un pc juste pour l'utiliser il s'en bellek de ce genre de problemes...
Sauf que Gnu/linux existe *justement* parce qu'il est libre, les drivers libres marchent bien, sans problèmes lors d'une mise à jour de noyau, *justement* parce qu'ils sont libres. Les drivers proprio posent problème sous linux *justement* parce qu'ils ne sont pas libres.
Alors "le mec" il peut s'en battre les belleks en rythme, il a même le droit de vouloir la grossesse à six mois et de manifester contre les manifestants, ça reste de la luthomiction de compète. Fondamentalement si pas de libre, pas de linux. Point final. Les cas d'arrangements entre proprio et libre sont des cas particuliers voués à l'ephemère ou à la niche industrielle. Pour les linux grand public il faut du libre. Si tu es interéssé, même sans être technicien, tu fais quelques choses *pour* le libre :
- choisir tes constructeurs/vendeurs selon leur linux-friendily
- coder
- réclamer auprès des constructeurs/vendeurs
- tester
- gueuler auprès des constructeurs/vendeurs
- traduire
- faire connaitre les "bons" constructeurs/vendeurs.
...
bref, amha, tu prends le problème à l'envers (et tu aimes les discussions mouvementées et les gros mots :)
[^] # Re: Mouais
Posté par Slauncha (site web personnel) . Évalué à 0.
Absolument !
Un OS est censé s'adapter à ton matériel, savoir évolué avec celui-ci, non ? Si à chaque changement de version (Windows 2000->XP, kernel 2.4-> kernel 2.6) on m'oblige/pousse à changer la moitié de mon matos, perso j'appelle pas ça un OS.
Tout OS qui se respecte doit assurer un minimum de compatibilité ascendante !
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Mouais
Posté par Slauncha (site web personnel) . Évalué à 4.
Ce que je confirme !!! Car pour moi primo, un système d'exploitation doit évoluer avec ton matériel et non le contraire (changer ton imprimante/scanner/processeur/... car non plus supporter, faut pas charier) . Et secundo, un soft (peu importe le soft : OS, suite bureautique, ...) doit assurer un minimum de compatibilité ascendante !!
Tu soulignes le fait que que tu n'as jamais entendu parler de matos supporter en 2.4 et qui ne l'était plus en 2.6, je suis dans la même situation que toi. On ne peut pas en dire autant sur le passage Win2000 et WinXP.
Bref, depuis quand MS fait des OS ? (sarcasme)
[^] # Re: Mouais
Posté par pasBill pasGates . Évalué à 1.
Entre Win98 et XP j'imagines parfaitement vu que ce sont 2 lignees d'OS completement differentes, mais je serais interesse de savoir quel probleme t'as eu entre 2000 et XP
[^] # Re: Mouais
Posté par Slauncha (site web personnel) . Évalué à 3.
Fait on choix ...
[^] # Re: Mouais
Posté par Anonyme . Évalué à 2.
# Euh...
Posté par pasBill pasGates . Évalué à 3.
Ben pour Vista c'est simple, la grande majorite des drivers fonctionne encore.
C'est l'avantage, sous Windows les drivers ont une interface normalisee qui ne change pas(ou tres tres tres peu) entre 2 OS, resultat, la plupart des drivers de Windows 2000 fonctionnent sur Windows 2003 et fonctionneront sur Windows Vista
[^] # Re: Euh...
Posté par Nicolas Schoonbroodt . Évalué à 6.
(donc cette approche à des avantages et des inconvénients. Mais pour les gens qui ont un driver libre et qui demandent à être intégrés dans le noyau, leur driver évolue avec l'interface. Ce n'est donc un problème que pour les drivers propriétaires, ou les drivers qui ne veulent pas être intégrés)
[^] # Re: Euh...
Posté par kraman . Évalué à 3.
comme tout ici bas.
Une interface mouvante oblige a maitenir en permanence l'ensemble des pilotes.
C'est pas forcement tres marrant non plus.
Apres tout est question de compromis simplicite de dev/maintenance/utilisateur etc...
Comme partout en fait.
[^] # Re: Euh...
Posté par ondex . Évalué à 1.
Je ne vois pas trop le problème. Lorsque le pilote est stabilisé, il n'y a pas de raison d'avoir besoin de la nouvelle interface.
Je pense que figer une interface est une très bonne idée, tout comme avoir une interface pour gérer la compatibilité (tant que cette compatibilité n'est pas un frein)
Mais bon, c'est une vieille discution. J'ai déjà eu l'occasion d'exposer mon point de vue ici : https://linuxfr.org/~DrFreuderick/21587.html
[^] # Re: Euh...
Posté par Sylvain Sauvage . Évalué à 4.
[^] # Re: Euh...
Posté par ondex . Évalué à 3.
Cette "absurdité" me semble être le fruit d'une vision à court terme.
L'exemple de l'interface "USB" est pris dans le fichier. Si une vraie réflexion (pas 2 jours mais qques semaines) était faite sur les besoins d'une interface interne, je suis sûr que les développeurs ne passeraient pas leurs temps à décider de changer ceci, cela, ...
De si nombreux changements montre que les besoins n'ont pas été anticipés.
L'argument sur le problème de sécurité me parait aussi un peu tordu. Dans quelle proportion la correction d'une faille impose la modification de l'API ? Bien sûr ce cas peut exister mais il doit être relativement rare je pense.
Je ne suis pas contre toute évolution d'une API mais elle ne devrait pas être en constante évolution.
[^] # Re: Euh...
Posté par Gilles Gagniard (site web personnel) . Évalué à 4.
Ding. Perdu. Ca arrive fréquemment en fait ! On se rend compte que la seule manière de bien corriger une faille, c'est d'ajouter un argument a une fonction; par exemple une méthode qui prend une grosse structure, et on se rend compte que la seule manière de pas se faire avoir par un buffer overflow, c'est de passer en argument la taille de la dite structure ... et blam, API cassée.
Alors oui je sais, chez les Bisounours, on pense directement à toutes les failles possibles et à passer tous les paramètres qu'il faut dès le début. Mais dans le monde réel, personne ne fait le design parfait dès le premier jet.
Tiens, d'ailleurs faudrait demander à Linus pourquoi il s'est fait chier à écrire Freax, Linux 0.x, Linux 1.x, Linux 2.0.x etc ..... il aurait pu faire Linux 2.6 directement en 1991, on aurait eu moins de problèmes quand même, l'API aurait changé moins souvent ;)
[^] # Re: Euh...
Posté par pasBill pasGates . Évalué à 3.
Ben on va prendre au hasard Windows hein, combien de fois on a casse l'API des drivers depuis Windows 2000 pour raison de securite ? Pourtant les failles ont ete corrigees, comme quoi c'est faisable.
Alors oui je sais, chez les Bisounours, on pense directement à toutes les failles possibles et à passer tous les paramètres qu'il faut dès le début. Mais dans le monde réel, personne ne fait le design parfait dès le premier jet.
Non, mais on fait des interfaces decentes en y passant un peu de temps, l'exemple de Windows prouve que c'est possible vu qu'on y arrive.
[^] # Re: Euh...
Posté par lolop (site web personnel) . Évalué à 3.
Mauvais exemple... une grande partie des failles Windows proviens de son architecture, et pour la changer... il faudrais modifier l'API... donc casser la compatibilité.
Non, on embauche beaucoup de développeurs pour essayer d'un côté de faire évoluer le bouzin, et de l'autre d'écrire des couches de compatibilité qui masquent les évolutions. Ca demande énormément de moyens, Microsoft les a... et pourtant c'est encore lourd et ça fait des projets ingérables donc du retard.
Je suis d'accord que des APIs plus stables seraient plus agréables pour les développeurs (moins à revenir sur le code) et dans cette optique pour les utilisateurs (des drivers proprios qui continuent à tourner). Par contre, je comprend les arguments des développeurs du noyau qui cherchent à l'améliorer et qui de temps à autre ont besoin de modifier certaines façons de faire.
Par exemple, passer d'un gros lock vers des locks plus atomiques, ça change la façon dont le noyau travaille, et je ne suis pas sûr que ça se fasse facilement sans ajuster aussi les drivers.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Euh...
Posté par pasBill pasGates . Évalué à 2.
Ben fait seulement, cites moi ldonc es failles presentes qui demanderaient le changement de l'API des drivers.
Par exemple, passer d'un gros lock vers des locks plus atomiques, ça change la façon dont le noyau travaille, et je ne suis pas sûr que ça se fasse facilement sans ajuster aussi les drivers.
Et pourtant si, on l'a fait dans Windows. La raison est extremement simple, le lock, il est pris dans l'appel de fonction, pas en externe par le driver, resultat tu es totalement libre de changer la granularite du lock comme tu en as envie sans affecter le driver.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Euh...
Posté par pasBill pasGates . Évalué à 2.
La plupart des virus ne sont deja pas lies aux drivers et operent en user-mode, donc bon...
Et t'es au courant que les failles c'est pas uniquement dans les interfaces mais quasiment tout le temps dans le code lui-meme hein ?
il semble que l'api windows a change le seul truc c'est qu'il y a des couches de compatibilite pour garder les vieilles api. Ca doit etre un joli bordel d'ailleurs ce truc surtout niveau securite...
Cites moi donc combien de choses ont change entre Win2000 et XP/2003 niveau interface, tu vas pas trouver grand-chose.
[^] # Re: Euh...
Posté par TImaniac (site web personnel) . Évalué à 3.
Euh, je vois pas en quoi il est impossible de garder le support de l'ancienne interface tout en migrant les drivers qui peuvent l'être vers la nouvelle. Quand l'ancienne interface ne peut vraiment plus être supportée, cela ne doit pas se faire tous les 6 mois.
Bref, il est tout à fait possible de garder une compatibilité sans pour autant freiner les évolutions, c'est bidon comme argument de prétendre que compatibilité s'oppose à évolution.
Je vais reprendre encore mon cas perso, mais fut un temps, mon entrée tuner TV marchait (avec des pilotes libres et tout), et un jour, pouf, amarche plus. Le driver n'a plus le même comportement suite à une évolution. Youpi, je peux même pas garder l'ancien driver. Où est l'avantage et l'intérêt pour le end-user ?
Alors l'excuse de "oué on veut forcer à migrer vers la nouvelle interface" c'est pipo : ca fait chier le end-user que je suis, car au final tout n'est pas migrer, et on pert le support d'une partie du matos. Génial.
[^] # Re: Euh...
Posté par Agalaz . Évalué à 1.
A partir de là, on peut discuter de l'intérêt d'avoir une compatibilité maintenue..
[^] # Re: Euh...
Posté par Nicolas Schoonbroodt . Évalué à 4.
[^] # Re: Euh...
Posté par cxente . Évalué à 1.
--> [out]
[^] # Re: Euh...
Posté par Agalaz . Évalué à 1.
Doux rêveurs.
[^] # Re: Euh...
Posté par Nicolas Schoonbroodt . Évalué à 2.
# $*ù^p de système
Posté par jeje99 . Évalué à 1.
D'un point de vue technique, je n'arrive pas à comprendre pourquoi. Je n'ai jamais développé un driver pour windows mais ça doit être la galère alors que sous linux, c'est plutôt facile et la doc et l'acces au sources du kernel aident largement. Je suis sur que le temps (l'argent) investi pour le développement d'un driver sous Linux est largement moins grand pour un driver équivalent sous windows. Ca vaudrait donc la peine de développer ce driver à la sortie d'un nouveau produit pour agrandir la quantité de client potentiel !
Le problème c'est peut être que les constructeurs ne veulent pas donner les sources de leur driver. Et ça je ne comprend vraiment pas pourquoi, encore que des géant comme adobe ou macromédia ne veulent pas "ouvrir" leur gagne pain je comprend. Mais que nvidia ou ati ouvre les modules pour discuter avec les chips, ils ont tout à gagner, enfin pour moi un driver ne révèle pas forcément tout les secrets de fabrication du chip....
En y réfléchissant le problème viens peut être d'un problème de garantie légal. Et que le kernel Linux fait encore peur aux constructeurs pour qu'il puisse garantir le bon fonctionnement de leur matériel, c'est vrai que windows à toujours fait preuve d'une stabilité exemplaire (je suis ironique)... Il y a des mystères dans la vie qu'on comprend pas :-)
[^] # Re: $*ù^p de système
Posté par Markov . Évalué à 4.
Cependant cela ne me semble pas etre le probleme le plus important. Pour moi avoir un noyau linux avec module binaire c'est renoncer a tout ce qui fait l'interet du libre a savoir connaitre ce qu'il se passe ou du moins en avoir la possibilite.
Comment savoir ce que font les modules binaire des cartes graphiques ? N'introduisent t'ils pas des bugs, des failles ? Comment verifier la qualite de leur code ? De plus qd le constructeur decide de ne plus supporter une gamme de produit je dois jeter mon materiel si je veux passer a un noyau plus recent ?
Bref pour moi l'important c'est d'avoir des drivers libre qui est important. Et les constructeurs ont a cet egard des comportement intriguant. Par exemple pour les cartes graphiques ati r200, r300, r400 ou les cartes nvidia, par reverse engineering l'on connait suffisament precisement le fonctionnement de ces cartes. Mais les constructeurs ne veulent pas donner les specifications manquantes (certains registre ne sont pas compris et les drivers libre y ecrivent des valeurs dites magiques ;)) Bref ils n'ont pas de gros secret a cacher alors pourquoi ne pas donner la liste des registres et leur fonctions ?
Nota bene: DSL pour l'ortho j'ecris cela entre deux trains :)
[^] # Re: $*ù^p de système
Posté par jeje99 . Évalué à 4.
Et comme je le disais dans mon commentaire, libérer un logiciel propriétaire, je comprend que ça ne soit pas évidnet mais un driver ou les spec du chip ? je ne comprend pourquoi c'est si dur je croyais c'était le matériel en lui même qui était important...
[^] # Re: $*ù^p de système
Posté par pierthi . Évalué à 1.
Euh, tu sors ça de ton chapeau ? Perso, j'aurais tendance à dire que c'est la même merde entre les deux. Dialoguer avec du matos, c'est toujours délicat : débuguage difficile, programmation ultra bas-niveau, plantage latent, specif bancale, ... tout les ingrédients pour enfoncer joyeusement des clous avec la tête ...
Pour ce qui est de nvidia et d'ATI ne voulant pas libérer leurs specs, ben, moi je vois plein de raisons :
- Problèmes de brevets US.
- Bridages logiciels qu'il vaut mieux planquer dans un bon gros binaire.
- Marché ridiculement petit, demande nulle.
- Bidouille logicielle dans le rendu (revient au point 2) diminuant l'effet marketing.
- etc ...
[^] # Re: $*ù^p de système
Posté par Sylvain Sauvage . Évalué à 6.
- les pilotes (Linux) libres peuvent partager du code ;
- les pilotes propriétaires sont obligés de réinventer la roue à chaque fois.
On va me répondre que Windows offre plein d'api pour programmer des pilotes. Seulement voilà, comment préparer des api pour factoriser du code auquel on a pas accès ?
[^] # Re: $*ù^p de système
Posté par Markov . Évalué à 4.
Apres il est vrai que leur drivers utilisent souvent des astuces afin d'augmenter le framerate de certains jeux. Mais en donnant leur specs ils ne donnent pas les astuces qu'ils utilisent. Les specifications d'une carte graphique c'est grosso modo une liste de registre (des addresses memoire) avec leur fonctions (ce qu'on peut y lire ou y ecrire et ce que cela realise).
[^] # Re: $*ù^p de système
Posté par Jean-Philippe (site web personnel) . Évalué à 2.
Nvidia s'en fout que quelques overclockeurs passent outre vu que la plupart d'entre eux achèteront quand même régulièrement le haut de gamme.
Ce bridage ne concerne donc que quelques modèles précis et personnes précises vu que la plupart des gens ne vont rien faire pour en benificer car il faut utiliser un logiciel précis, trouver quelques réglages etc...
Sous linux il en est tout autre car si les codeurs possèderaient toutes les specs ils pourraient coder de bons pilotes qui par défaut passeraient outre les bridages, et cela sans rien à faire pour l'utilisateur.
Cela voudrait donc peut-etre dire d'un autre côté que la part des utilisateurs de linux deviendrait trop importante ?
[^] # Re: $*ù^p de système
Posté par kraman . Évalué à 2.
ou qu'il ya des codeurs sous windows qui pourrait aussi utiliser ces specs (pour faire un pilote non signe, certes, mais c'est pas trop un probleme).
[^] # Re: $*ù^p de système
Posté par Jean-Philippe (site web personnel) . Évalué à 2.
[^] # Re: $*ù^p de système
Posté par dinomasque . Évalué à 2.
Je me souviens d'avoir vu Quake 3 transfiguré en installant le bon driver alternatif sur mon Windows.
BeOS le faisait il y a 20 ans !
[^] # Re: $*ù^p de système
Posté par farib . Évalué à 2.
[^] # Re: $*ù^p de système
Posté par pierthi . Évalué à 2.
J'avais une p..n de carte ATI Rage XL sur un vieux Windows 2000 (ouais, je sais la machine n'est pas neuve). Les perfs n'étaient pas super avec le driver de Windows, mais je pouvais avoir du 1280x1024 en 24bits. Cool, je vais voir sur le site d'ATI pour télécharger un pilote plusse mieux. Install et .... driver bridé à 1280x1024 en 16bits ou 1152x864 en 32bits, que dalle du mode 1280x1024 en 24bits.
Bon, dans ce cas, le bridage est ridicule, plus dû à de l'incompétence qu'autre chose. Mais bon, j'imagine tout à fait une fonctionnalité mal testée sur certaine série de carte, désactivée logicielement.
Sinon, J'ai développé il y a quelques années quelques drivers pour des machines professionnelles, si tu savais le nombre de bridage purement logiciel qui était contenu dans ses machines, dont un scanner, dont la vitesse se modifiait par l'upload de clés purement logicielles, vendue la peau du cul évidemment. Pas de nom, pas de marque, j'ai signé un NDA de toute façon.
[^] # Re: $*ù^p de système
Posté par farib . Évalué à 1.
. Je n'ai jamais développé un driver pour windows
Je suis sur que le temps (l'argent) investi pour le développement d'un driver sous Linux est largement moins grand pour un driver équivalent sous windows
Moi je n'ai developpe de pilote ni sous linux ni sous windows, mais je suis sur que c'est aussi difficile dans les deux cas.
NB: je vois pas en quoi avoir les sources ca t'aide a developper un driver, t'as une api, point barre.
[^] # Re: $*ù^p de système
Posté par Médéric RIBREUX (site web personnel) . Évalué à 2.
Si tu es développeur, je t'embauche tout de suite...
Un type capable de coder sans aucun exemple ni aucune inspiration, les yeux fermés, j'ai encore jamais vu !!
[^] # Re: $*ù^p de système
Posté par farib . Évalué à 1.
Quand je code avec une bibliotheque, effectivement, je regarde des exemples, je lis la doc, mais generalement, je cherche pas trop dans son source, et si c'est le cas, c'est que docs et exemples sont pas suffisemment documentes.
[^] # Re: $*ù^p de système
Posté par Sylvain Sauvage . Évalué à 2.
[^] # Re: $*ù^p de système
Posté par jeje99 . Évalué à 1.
Aussi est - ce que n'importe qui peux faire un driver pour windows ou est ce qu'il faut être certifié (c'est à dire payer une coquette somme) ?
[^] # Re: $*ù^p de système
Posté par pasBill pasGates . Évalué à 4.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.