Concernant les composants propriétaires (Wifi, vidéo...) il est vrai qu'il existe des modules (propriétaires) que ne fonctionnent que sur la distribution pré-chargée.
bin espérons qu'ils vont capitaliser sur l'expérience alors... car là, le problème avait été pris à l'envers puisque pour bien faire :
- il vaut mieux sélectionner du matériel dont le support est déjà éprouvé dans le kernel (éviter l'épisode poulsbo avec Intel par exemple, comme quoi il n'y a pas que HP qui s'y fait prendre)
- ou contribuer à améliorer le support du matériel, mais pas dans un pilote non libre et si possible fournir les spécifications (c'est le rôle de l'intégrateur - donc HP ici - de faire du bon travail de sélection du matériel à prendre en compte ou rejeter)
- Novell/Suse aurait dû jouer son rôle de conseil : maintenir l'utilisateur dans une vieille version de kernel inmaintenable tout cela à cause d'un mauvais choix de pilote/matériel, c'est tout simplement dommage quand d'autres constructeurs sont plus ouverts
On voit bien qu'une fois les choix (mauvais) initiaux faits il est difficile de rétablir une situation correcte, autant faire les bons choix au début.
Oui, il peut être opportun de prendre le tout dernier matériel disponible, mais l'intégrateur a généralement 6 mois pour faire prendre en compte ses spécifications par le constructeur dans le noyau ou le pilote approprié et zou au moment où c'est commercialisé le pilote est disponible en libre (ou dans la foulée). Ça évite les situations où l'intégrateur travaille contre le constructeur à tenter de trouver des contournements avec des pilotes non libres alors qu'ils pourraient travailler à 2 pour améliorer un pilote libre qui leur bénéficiera (au passage ils auront l'expérience du sujet et auront encore une avance sur leurs concurrents). Ce n'est pas une histoire d'API stable, c'est bien d'être en mesure de travailler de concert avec plus de 2 interlocuteurs (le constructeur, l'intégrateur, la distribution, les développeurs de modules kernel, les utilisateurs...).
[^] # Re: Avant de se réjouir trop vite...
Posté par BAud (site web personnel) . En réponse au journal Un Classmate HP mini 100e sous Linux (et Windows aussi). Évalué à 6.
bin espérons qu'ils vont capitaliser sur l'expérience alors... car là, le problème avait été pris à l'envers puisque pour bien faire :
- il vaut mieux sélectionner du matériel dont le support est déjà éprouvé dans le kernel (éviter l'épisode poulsbo avec Intel par exemple, comme quoi il n'y a pas que HP qui s'y fait prendre)
- ou contribuer à améliorer le support du matériel, mais pas dans un pilote non libre et si possible fournir les spécifications (c'est le rôle de l'intégrateur - donc HP ici - de faire du bon travail de sélection du matériel à prendre en compte ou rejeter)
- Novell/Suse aurait dû jouer son rôle de conseil : maintenir l'utilisateur dans une vieille version de kernel inmaintenable tout cela à cause d'un mauvais choix de pilote/matériel, c'est tout simplement dommage quand d'autres constructeurs sont plus ouverts
On voit bien qu'une fois les choix (mauvais) initiaux faits il est difficile de rétablir une situation correcte, autant faire les bons choix au début.
D'autant qu'à lire GKH, http://broadcast.oreilly.com/2008/10/how-linux-supports-more(...) il y a du monde prêt à travailler, mais dans de bonnes conditions ;-)
Oui, il peut être opportun de prendre le tout dernier matériel disponible, mais l'intégrateur a généralement 6 mois pour faire prendre en compte ses spécifications par le constructeur dans le noyau ou le pilote approprié et zou au moment où c'est commercialisé le pilote est disponible en libre (ou dans la foulée). Ça évite les situations où l'intégrateur travaille contre le constructeur à tenter de trouver des contournements avec des pilotes non libres alors qu'ils pourraient travailler à 2 pour améliorer un pilote libre qui leur bénéficiera (au passage ils auront l'expérience du sujet et auront encore une avance sur leurs concurrents). Ce n'est pas une histoire d'API stable, c'est bien d'être en mesure de travailler de concert avec plus de 2 interlocuteurs (le constructeur, l'intégrateur, la distribution, les développeurs de modules kernel, les utilisateurs...).