>- ne pas a se faire chier a le coder
C'est leur boulot quand même
> dis ca aux ingénieurs en microelectronique qui concoivent la puce "ouais c'est votre boulot de faire le driver" .
Ils vont bien rigoler je pense.
Une boite de hard devrais justement faire principalement du hard (bien entendu faire un dialogue avec ceux qui code les drivers, pour que ca soit simple pour tout le monde;)) pas principalement du soft.
>Négligeable malheureusement dans l'état actuel du marché (par rapport aux gamers,...)
négligeable oui et non.
Les gamers il y a effectivement les nvidiot et les fanatic , mais la majorité des gamers , amha , achete la cg la plus performante au moment ou ils l'achetent donc soit l'une, soit l'autre.
Tandis qu'une base fixe, qui peut entrainer une base plus large c'est négligeable, mais pas forcément tant que ca (sans compter tout le marché pro qui est sous unix et qui a besoin de 3D).
Ca contrebalance tous les inconvénients?
- s'arranger pour que libérer les sources ne viole aucun brevet/licence/pacte commercial (chose suffisante pour ne pas faire quoi que ce soit tant que c'est pas régler)
Ca c'est typiquement des problemes liés à une logique propriétaire.
le pacte commercial , les dvp externes n'en ont que faire, et si on pense dés le début a liberer les sources ont se débrouille pour.
Les licence/brevet dans le hard: une 'glue' hardware qui permet de faire une stricte conformance aux api de plus haut niveau dx ou opengl devrait permettre aussi d'éviter ce genre de probleme.
alors ensuite je dis pas 'c'est simple, ils sont tous trop con'.
Je veux juste dire que des avantages a utiliser des drivers libre, il y en a aussi pour le constructeur, mais il faut bien entendu qu'il y ait pensé avant de concevoir entièrement son produit.
- donner de précieuses informations aux concurrents
ca par contre ca ne tient pas dés qu'on saute une génération.
- perdre le contrôle sur l'évolution du code
rien ne les empeche d'etre les principaux contributeurs et de demander a etre mainteneur. Par contre si ils font pas leurs boulot, le fork est toujours possible.
Bref, je me fais l'avocat du diable, et je me fais moinsser. A+
Tant que le post est pas insultant et argumenté, pas par moi en tout cas ;)
[^] # Re: ouverture des driver, c'est quoi le problème au juste ?
Posté par briaeros007 . En réponse au journal Les modules kernel propriétaires.. Évalué à 2.
C'est leur boulot quand même
> dis ca aux ingénieurs en microelectronique qui concoivent la puce "ouais c'est votre boulot de faire le driver" .
Ils vont bien rigoler je pense.
Une boite de hard devrais justement faire principalement du hard (bien entendu faire un dialogue avec ceux qui code les drivers, pour que ca soit simple pour tout le monde;)) pas principalement du soft.
>Négligeable malheureusement dans l'état actuel du marché (par rapport aux gamers,...)
négligeable oui et non.
Les gamers il y a effectivement les nvidiot et les fanatic , mais la majorité des gamers , amha , achete la cg la plus performante au moment ou ils l'achetent donc soit l'une, soit l'autre.
Tandis qu'une base fixe, qui peut entrainer une base plus large c'est négligeable, mais pas forcément tant que ca (sans compter tout le marché pro qui est sous unix et qui a besoin de 3D).
Ca contrebalance tous les inconvénients?
- s'arranger pour que libérer les sources ne viole aucun brevet/licence/pacte commercial (chose suffisante pour ne pas faire quoi que ce soit tant que c'est pas régler)
Ca c'est typiquement des problemes liés à une logique propriétaire.
le pacte commercial , les dvp externes n'en ont que faire, et si on pense dés le début a liberer les sources ont se débrouille pour.
Les licence/brevet dans le hard: une 'glue' hardware qui permet de faire une stricte conformance aux api de plus haut niveau dx ou opengl devrait permettre aussi d'éviter ce genre de probleme.
alors ensuite je dis pas 'c'est simple, ils sont tous trop con'.
Je veux juste dire que des avantages a utiliser des drivers libre, il y en a aussi pour le constructeur, mais il faut bien entendu qu'il y ait pensé avant de concevoir entièrement son produit.
- donner de précieuses informations aux concurrents
ca par contre ca ne tient pas dés qu'on saute une génération.
- perdre le contrôle sur l'évolution du code
rien ne les empeche d'etre les principaux contributeurs et de demander a etre mainteneur. Par contre si ils font pas leurs boulot, le fork est toujours possible.
Bref, je me fais l'avocat du diable, et je me fais moinsser. A+
Tant que le post est pas insultant et argumenté, pas par moi en tout cas ;)