Est-ce que c'est possible d'avoir des wrappers drivers windows pour
tous les types de drivers (ex: ndiswrapper), et si oui, est-ce que ca
serait vraiment souhaitable?
Est-ce que c'est possible d'avoir des wrappers drivers windows pour tous les types de drivers (ex: ndiswrapper),
Je pense que pour la majorite des peripheriques, ca doit etre possible.
et si oui, est-ce que ca serait vraiment souhaitable?
Non, non et 1000 fois non! 1) c'est derangeant dans le principe d'avoir du code non libre 2) pas moyen de deboguer le driver, les developpeurs du kernel sont a la merci du constructeur (dans le meilleur des cas) ou de MS (encore pire) 3) on oublie les architectures non X86?
Bon d'accord ca ne fait que 3 fois non. Mais je suis sur qu'on peut trouver d'autres objections...
-- Alain Borel
Johan <neoillogic@hotmail.com> wrote:
Est-ce que c'est possible d'avoir des wrappers drivers windows pour
tous les types de drivers (ex: ndiswrapper),
Je pense que pour la majorite des peripheriques, ca doit etre possible.
et si oui, est-ce que ca
serait vraiment souhaitable?
Non, non et 1000 fois non!
1) c'est derangeant dans le principe d'avoir du code non libre
2) pas moyen de deboguer le driver, les developpeurs du kernel sont a la merci
du constructeur (dans le meilleur des cas) ou de MS (encore pire)
3) on oublie les architectures non X86?
Bon d'accord ca ne fait que 3 fois non. Mais je suis sur qu'on peut trouver
d'autres objections...
Est-ce que c'est possible d'avoir des wrappers drivers windows pour tous les types de drivers (ex: ndiswrapper),
Je pense que pour la majorite des peripheriques, ca doit etre possible.
et si oui, est-ce que ca serait vraiment souhaitable?
Non, non et 1000 fois non! 1) c'est derangeant dans le principe d'avoir du code non libre 2) pas moyen de deboguer le driver, les developpeurs du kernel sont a la merci du constructeur (dans le meilleur des cas) ou de MS (encore pire) 3) on oublie les architectures non X86?
Bon d'accord ca ne fait que 3 fois non. Mais je suis sur qu'on peut trouver d'autres objections...
-- Alain Borel
talon
wrote:
Johan wrote:
Est-ce que c'est possible d'avoir des wrappers drivers windows pour tous les types de drivers (ex: ndiswrapper),
Je pense que pour la majorite des peripheriques, ca doit etre possible.
et si oui, est-ce que ca serait vraiment souhaitable?
Non, non et 1000 fois non! 1) c'est derangeant dans le principe d'avoir du code non libre 2) pas moyen de deboguer le driver, les developpeurs du kernel sont a la merci du constructeur (dans le meilleur des cas) ou de MS (encore pire)
Parcequ'ils ne sont pas à la merci du constructeur pour le hardware et son firmware?
3) on oublie les architectures non X86?
Ca existe?
Bon d'accord ca ne fait que 3 fois non. Mais je suis sur qu'on peut trouver d'autres objections...
Le hardware avec son firmware, c'est une boite noire qui est programmée par le driver. Utiliser le driver Windows ce n'est qu'étendre la boite noire un peu plus loin ...
-- Michel Talon
Alain.Borel@icma.unil.ch wrote:
Johan <neoillogic@hotmail.com> wrote:
Est-ce que c'est possible d'avoir des wrappers drivers windows pour
tous les types de drivers (ex: ndiswrapper),
Je pense que pour la majorite des peripheriques, ca doit etre possible.
et si oui, est-ce que ca
serait vraiment souhaitable?
Non, non et 1000 fois non!
1) c'est derangeant dans le principe d'avoir du code non libre
2) pas moyen de deboguer le driver, les developpeurs du kernel sont a la merci
du constructeur (dans le meilleur des cas) ou de MS (encore pire)
Parcequ'ils ne sont pas à la merci du constructeur pour le hardware et son
firmware?
3) on oublie les architectures non X86?
Ca existe?
Bon d'accord ca ne fait que 3 fois non. Mais je suis sur qu'on peut trouver
d'autres objections...
Le hardware avec son firmware, c'est une boite noire qui est programmée par le
driver. Utiliser le driver Windows ce n'est qu'étendre la boite noire un peu
plus loin ...
Est-ce que c'est possible d'avoir des wrappers drivers windows pour tous les types de drivers (ex: ndiswrapper),
Je pense que pour la majorite des peripheriques, ca doit etre possible.
et si oui, est-ce que ca serait vraiment souhaitable?
Non, non et 1000 fois non! 1) c'est derangeant dans le principe d'avoir du code non libre 2) pas moyen de deboguer le driver, les developpeurs du kernel sont a la merci du constructeur (dans le meilleur des cas) ou de MS (encore pire)
Parcequ'ils ne sont pas à la merci du constructeur pour le hardware et son firmware?
3) on oublie les architectures non X86?
Ca existe?
Bon d'accord ca ne fait que 3 fois non. Mais je suis sur qu'on peut trouver d'autres objections...
Le hardware avec son firmware, c'est une boite noire qui est programmée par le driver. Utiliser le driver Windows ce n'est qu'étendre la boite noire un peu plus loin ...
-- Michel Talon
Alain.Borel
wrote:
wrote:
Johan wrote: Non, non et 1000 fois non! 1) c'est derangeant dans le principe d'avoir du code non libre 2) pas moyen de deboguer le driver, les developpeurs du kernel sont a la merci du constructeur (dans le meilleur des cas) ou de MS (encore pire)
Parcequ'ils ne sont pas ? la merci du constructeur pour le hardware et son firmware?
Firmware: y'en a pas forc?ment, je crois. Mais c'est effectivement un bon point... d'ailleurs abord? r?cemment par Stallman en parlant du BIOS. Mat?riel: ?videmment, faut bien l'acheter chez quelqu'un. Mais le soft qui va avec, c'est possible pour tout un chacun de le modifier et de le corriger (? condition bien sur d'avoir les connaissances necessaires). Et les drivers fournis par les constructeurs ne sont pas forcement sans failles! Donc c'est dans l'interet de tout le monde si des gens competents peuvent ameliorer ces drivers... y compris pour le constructeur qui peut economiser un peu de developpement.
Sans compter qu'au niveau performance, il peut y avoir un inconvenient: l'architecture du driver peut etre plus ou moins compatible avec celle du kernel, avec parfois une communication un peu boiteuse entre les 2.
3) on oublie les architectures non X86?
Ca existe?
C'est un gag? PowerPC, ARM, 680x0, SPARC, Alpha, j'en passe... Linux tourne aussi sur ces b?canes!
-- Alain Borel
talon@lpthe.jussieu.fr wrote:
Alain.Borel@icma.unil.ch wrote:
Johan <neoillogic@hotmail.com> wrote:
Non, non et 1000 fois non!
1) c'est derangeant dans le principe d'avoir du code non libre
2) pas moyen de deboguer le driver, les developpeurs du kernel sont a la merci
du constructeur (dans le meilleur des cas) ou de MS (encore pire)
Parcequ'ils ne sont pas ? la merci du constructeur pour le hardware et son
firmware?
Firmware: y'en a pas forc?ment, je crois. Mais c'est effectivement un bon point...
d'ailleurs abord? r?cemment par Stallman en parlant du BIOS.
Mat?riel: ?videmment, faut bien l'acheter chez quelqu'un. Mais le soft qui va avec,
c'est possible pour tout un chacun de le modifier et de le corriger (? condition
bien sur d'avoir les connaissances necessaires). Et les drivers fournis par les
constructeurs ne sont pas forcement sans failles! Donc c'est dans l'interet de tout
le monde si des gens competents peuvent ameliorer ces drivers... y compris pour
le constructeur qui peut economiser un peu de developpement.
Sans compter qu'au niveau performance, il peut y avoir un inconvenient: l'architecture
du driver peut etre plus ou moins compatible avec celle du kernel, avec parfois une
communication un peu boiteuse entre les 2.
3) on oublie les architectures non X86?
Ca existe?
C'est un gag? PowerPC, ARM, 680x0, SPARC, Alpha, j'en passe... Linux tourne aussi
sur ces b?canes!
Johan wrote: Non, non et 1000 fois non! 1) c'est derangeant dans le principe d'avoir du code non libre 2) pas moyen de deboguer le driver, les developpeurs du kernel sont a la merci du constructeur (dans le meilleur des cas) ou de MS (encore pire)
Parcequ'ils ne sont pas ? la merci du constructeur pour le hardware et son firmware?
Firmware: y'en a pas forc?ment, je crois. Mais c'est effectivement un bon point... d'ailleurs abord? r?cemment par Stallman en parlant du BIOS. Mat?riel: ?videmment, faut bien l'acheter chez quelqu'un. Mais le soft qui va avec, c'est possible pour tout un chacun de le modifier et de le corriger (? condition bien sur d'avoir les connaissances necessaires). Et les drivers fournis par les constructeurs ne sont pas forcement sans failles! Donc c'est dans l'interet de tout le monde si des gens competents peuvent ameliorer ces drivers... y compris pour le constructeur qui peut economiser un peu de developpement.
Sans compter qu'au niveau performance, il peut y avoir un inconvenient: l'architecture du driver peut etre plus ou moins compatible avec celle du kernel, avec parfois une communication un peu boiteuse entre les 2.
3) on oublie les architectures non X86?
Ca existe?
C'est un gag? PowerPC, ARM, 680x0, SPARC, Alpha, j'en passe... Linux tourne aussi sur ces b?canes!
-- Alain Borel
talon
wrote:
Ca existe?
C'est un gag? PowerPC, ARM, 680x0, SPARC, Alpha, j'en passe... Linux tourne aussi sur ces b?canes!
Oui, c'est un gag, mais en même temps c'est sérieux. Mis à part PowerPC (et bien sûr les versions 64 bits de x86) toutes les autres architectures sont foutues à bref délai, et PowerPC a d'excellents OS pour lui.
-- Alain Borel
-- Michel Talon
Alain.Borel@icma.unil.ch wrote:
Ca existe?
C'est un gag? PowerPC, ARM, 680x0, SPARC, Alpha, j'en passe... Linux tourne aussi
sur ces b?canes!
Oui, c'est un gag, mais en même temps c'est sérieux. Mis à part PowerPC (et
bien sûr les versions 64 bits de x86) toutes les autres architectures sont
foutues à bref délai, et PowerPC a d'excellents OS pour lui.
C'est un gag? PowerPC, ARM, 680x0, SPARC, Alpha, j'en passe... Linux tourne aussi sur ces b?canes!
Oui, c'est un gag, mais en même temps c'est sérieux. Mis à part PowerPC (et bien sûr les versions 64 bits de x86) toutes les autres architectures sont foutues à bref délai, et PowerPC a d'excellents OS pour lui.
-- Alain Borel
-- Michel Talon
Miod Vallat
3) on oublie les architectures non X86?
Ca existe?
C'est un gag? PowerPC, ARM, 680x0, SPARC, Alpha, j'en passe... Linux tourne aussi sur ces b?canes!
Il tourne, mais personne ne s'en sert, donc ce n'est pas la peine de s'en soucier.
3) on oublie les architectures non X86?
Ca existe?
C'est un gag? PowerPC, ARM, 680x0, SPARC, Alpha, j'en passe... Linux tourne aussi
sur ces b?canes!
Il tourne, mais personne ne s'en sert, donc ce n'est pas la peine de
s'en soucier.
C'est un gag? PowerPC, ARM, 680x0, SPARC, Alpha, j'en passe... Linux tourne aussi sur ces b?canes!
Il tourne, mais personne ne s'en sert, donc ce n'est pas la peine de s'en soucier.
Alain.Borel
Miod Vallat wrote:
3) on oublie les architectures non X86?
Ca existe?
C'est un gag? PowerPC, ARM, 680x0, SPARC, Alpha, j'en passe... Linux tourne aussi sur ces b?canes!
Il tourne, mais personne ne s'en sert, donc ce n'est pas la peine de s'en soucier.
Et AMD64? On doit attendre que MS sorte sa version native pour s'en servir a plein regime, alors? Parce qu'on aura pas les drivers avant ca, si on suite cette logique de neuneu...
-- Alain Borel
Miod Vallat <miod@online.fr> wrote:
3) on oublie les architectures non X86?
Ca existe?
C'est un gag? PowerPC, ARM, 680x0, SPARC, Alpha, j'en passe... Linux tourne aussi
sur ces b?canes!
Il tourne, mais personne ne s'en sert, donc ce n'est pas la peine de
s'en soucier.
Et AMD64? On doit attendre que MS sorte sa version native pour s'en servir a plein regime,
alors? Parce qu'on aura pas les drivers avant ca, si on suite cette logique de neuneu...
C'est un gag? PowerPC, ARM, 680x0, SPARC, Alpha, j'en passe... Linux tourne aussi sur ces b?canes!
Il tourne, mais personne ne s'en sert, donc ce n'est pas la peine de s'en soucier.
Et AMD64? On doit attendre que MS sorte sa version native pour s'en servir a plein regime, alors? Parce qu'on aura pas les drivers avant ca, si on suite cette logique de neuneu...
-- Alain Borel
Miod Vallat
C'est un gag? PowerPC, ARM, 680x0, SPARC, Alpha, j'en passe... Linux tourne aussi sur ces b?canes!
Il tourne, mais personne ne s'en sert, donc ce n'est pas la peine de s'en soucier.
Et AMD64? On doit attendre que MS sorte sa version native pour s'en servir a plein regime,
AMD64 n'est que du i386 réchauffé, et bogué avec ça (d'ailleurs AMD fournit une correction par microcode... après les mises à jour de bios, les mises à jour de processeur !). Tant que Windows XP en édition 64 bits n'est pas disponible et largement diffusé, il est fort probable que d'autres bugs du CPU n'ont pas encore été trouvés... autant rester avec des machines fiables et éprouvées.
alors? Parce qu'on aura pas les drivers avant ca, si on suite cette logique de neuneu...
Quels drivers ? A part le processeur qui est gonflé, ça reste du PC standard avec des composants PC standard, donc le problème de drivers ne se pose pas.
C'est un gag? PowerPC, ARM, 680x0, SPARC, Alpha, j'en passe... Linux tourne aussi
sur ces b?canes!
Il tourne, mais personne ne s'en sert, donc ce n'est pas la peine de
s'en soucier.
Et AMD64? On doit attendre que MS sorte sa version native pour s'en servir a plein regime,
AMD64 n'est que du i386 réchauffé, et bogué avec ça (d'ailleurs AMD
fournit une correction par microcode... après les mises à jour de bios,
les mises à jour de processeur !). Tant que Windows XP en édition 64
bits n'est pas disponible et largement diffusé, il est fort probable que
d'autres bugs du CPU n'ont pas encore été trouvés... autant rester avec
des machines fiables et éprouvées.
alors? Parce qu'on aura pas les drivers avant ca, si on suite cette logique de neuneu...
Quels drivers ? A part le processeur qui est gonflé, ça reste du PC
standard avec des composants PC standard, donc le problème de drivers ne
se pose pas.
C'est un gag? PowerPC, ARM, 680x0, SPARC, Alpha, j'en passe... Linux tourne aussi sur ces b?canes!
Il tourne, mais personne ne s'en sert, donc ce n'est pas la peine de s'en soucier.
Et AMD64? On doit attendre que MS sorte sa version native pour s'en servir a plein regime,
AMD64 n'est que du i386 réchauffé, et bogué avec ça (d'ailleurs AMD fournit une correction par microcode... après les mises à jour de bios, les mises à jour de processeur !). Tant que Windows XP en édition 64 bits n'est pas disponible et largement diffusé, il est fort probable que d'autres bugs du CPU n'ont pas encore été trouvés... autant rester avec des machines fiables et éprouvées.
alors? Parce qu'on aura pas les drivers avant ca, si on suite cette logique de neuneu...
Quels drivers ? A part le processeur qui est gonflé, ça reste du PC standard avec des composants PC standard, donc le problème de drivers ne se pose pas.
Alain.Borel
Miod Vallat wrote:
alors? Parce qu'on aura pas les drivers avant ca, si on suite cette logique de neuneu...
Quels drivers ? A part le processeur qui est gonfl?, ?a reste du PC standard avec des composants PC standard, donc le probl?me de drivers ne se pose pas.
Et si je prends les composants dits "standard" et que je les mets dans un Alpha, j'ai pas de probleme de driver peut-etre? Je veux que mon systeme AMD64 fonctionne en mode 64-bit, proprement et sans passer par du 32-bit. Dans ce cas, j'ai besoin de drivers natifs AMD64, pas ceux pompes dans W2k/XP/2003! D'ou mon opinion qu'utiliser les drivers MS avec un wrapper est une idee assez mediocre. Ca condamne Linux au role de suiveur par rapport a Windows.
-- Alain Borel
Miod Vallat <miod@online.fr> wrote:
alors? Parce qu'on aura pas les drivers avant ca, si on suite cette logique de neuneu...
Quels drivers ? A part le processeur qui est gonfl?, ?a reste du PC
standard avec des composants PC standard, donc le probl?me de drivers ne
se pose pas.
Et si je prends les composants dits "standard" et que je les mets dans un Alpha,
j'ai pas de probleme de driver peut-etre? Je veux que mon systeme AMD64 fonctionne en
mode 64-bit, proprement et sans passer par du 32-bit. Dans ce cas, j'ai besoin
de drivers natifs AMD64, pas ceux pompes dans W2k/XP/2003!
D'ou mon opinion qu'utiliser les drivers MS avec un wrapper est une idee assez
mediocre. Ca condamne Linux au role de suiveur par rapport a Windows.
alors? Parce qu'on aura pas les drivers avant ca, si on suite cette logique de neuneu...
Quels drivers ? A part le processeur qui est gonfl?, ?a reste du PC standard avec des composants PC standard, donc le probl?me de drivers ne se pose pas.
Et si je prends les composants dits "standard" et que je les mets dans un Alpha, j'ai pas de probleme de driver peut-etre? Je veux que mon systeme AMD64 fonctionne en mode 64-bit, proprement et sans passer par du 32-bit. Dans ce cas, j'ai besoin de drivers natifs AMD64, pas ceux pompes dans W2k/XP/2003! D'ou mon opinion qu'utiliser les drivers MS avec un wrapper est une idee assez mediocre. Ca condamne Linux au role de suiveur par rapport a Windows.
-- Alain Borel
Nicolas George
Miod Vallat , dans le message <4107af36$0$493$, a écrit :
des machines fiables et éprouvées.
Euh, je ne suis pas sûr d'avoir tout suivi. Tu parlais bien du PC, là ?
Miod Vallat , dans le message <4107af36$0$493$626a14ce@news.free.fr>, a
écrit :
des machines fiables et éprouvées.
Euh, je ne suis pas sûr d'avoir tout suivi. Tu parlais bien du PC, là ?
Miod Vallat , dans le message <4107af36$0$493$, a écrit :
des machines fiables et éprouvées.
Euh, je ne suis pas sûr d'avoir tout suivi. Tu parlais bien du PC, là ?
Johan
Est-ce que c'est possible d'avoir des wrappers drivers windows pour tous les types de drivers (ex: ndiswrapper),
Je pense que pour la majorite des peripheriques, ca doit etre possible.
et si oui, est-ce que ca serait vraiment souhaitable?
Non, non et 1000 fois non! 1) c'est derangeant dans le principe d'avoir du code non libre 2) pas moyen de deboguer le driver, les developpeurs du kernel sont a la merci du constructeur (dans le meilleur des cas) ou de MS (encore pire) 3) on oublie les architectures non X86?
Bon d'accord ca ne fait que 3 fois non. Mais je suis sur qu'on peut trouver d'autres objections...
Oui, mais bon, en attendant d'avoir des drivers libres. Ca aiderait a
faire passer a linux les bonnes gens qu'ont des perifs non supportés (même si au bout on risque d'avoir des dégradations de performances). (me dites pas "mauvaise machine - changer machine" hein :p
@++
Est-ce que c'est possible d'avoir des wrappers drivers windows pour
tous les types de drivers (ex: ndiswrapper),
Je pense que pour la majorite des peripheriques, ca doit etre possible.
et si oui, est-ce que ca
serait vraiment souhaitable?
Non, non et 1000 fois non!
1) c'est derangeant dans le principe d'avoir du code non libre
2) pas moyen de deboguer le driver, les developpeurs du kernel sont a la merci
du constructeur (dans le meilleur des cas) ou de MS (encore pire)
3) on oublie les architectures non X86?
Bon d'accord ca ne fait que 3 fois non. Mais je suis sur qu'on peut trouver
d'autres objections...
Oui, mais bon, en attendant d'avoir des drivers libres. Ca aiderait a
faire passer a linux les bonnes gens qu'ont des perifs non supportés
(même si au bout on risque d'avoir des dégradations de performances).
(me dites pas "mauvaise machine - changer machine" hein :p
Est-ce que c'est possible d'avoir des wrappers drivers windows pour tous les types de drivers (ex: ndiswrapper),
Je pense que pour la majorite des peripheriques, ca doit etre possible.
et si oui, est-ce que ca serait vraiment souhaitable?
Non, non et 1000 fois non! 1) c'est derangeant dans le principe d'avoir du code non libre 2) pas moyen de deboguer le driver, les developpeurs du kernel sont a la merci du constructeur (dans le meilleur des cas) ou de MS (encore pire) 3) on oublie les architectures non X86?
Bon d'accord ca ne fait que 3 fois non. Mais je suis sur qu'on peut trouver d'autres objections...
Oui, mais bon, en attendant d'avoir des drivers libres. Ca aiderait a
faire passer a linux les bonnes gens qu'ont des perifs non supportés (même si au bout on risque d'avoir des dégradations de performances). (me dites pas "mauvaise machine - changer machine" hein :p
