Articles : Pré-installer Linux chez Dell (et ailleurs) : l'avis de Mark Shuttleworth d'Ubuntu
Posté par akauffmann (page perso, ). Modéré le 20 mars 2007.
Après le responsable marketing d'OpenOffice.org c'est au tour du créateur d'Ubuntu de donner son point de vue sur la question de la pré-installation de Linux dans les ordinateurs neufs, suite à la très médiatisée consultation publique lancée par Dell.
Il nous fait part sur son blog des difficultés d'une telle entreprise liées principalement selon lui aux faibles marges réalisées par les revendeurs si ils devaient se passer de la présence native de Windows mais également au caractère "tatillon" de ceux qui souhaitent non pas du "Linux" en général mais un GNU/Linux particulier à commencer par le choix de la distribution. Et de proposer quelques pistes pour améliorer la situation.
Une traduction française est disponible sur le blog de Framasoft.
PS : Suite à la consultation, Dell a mis en ligne un questionnaire afin de mieux étudier une éventuelle intégration de Linux dans ses gammes grand public. Vous avez jusqu'au 23 mars pour y participer.
Il nous fait part sur son blog des difficultés d'une telle entreprise liées principalement selon lui aux faibles marges réalisées par les revendeurs si ils devaient se passer de la présence native de Windows mais également au caractère "tatillon" de ceux qui souhaitent non pas du "Linux" en général mais un GNU/Linux particulier à commencer par le choix de la distribution. Et de proposer quelques pistes pour améliorer la situation.
Une traduction française est disponible sur le blog de Framasoft.
PS : Suite à la consultation, Dell a mis en ligne un questionnaire afin de mieux étudier une éventuelle intégration de Linux dans ses gammes grand public. Vous avez jusqu'au 23 mars pour y participer.
Pre-installing Linux by Mark Shuttleworth (719 hits)
La traduction sur le Framablog (2009 hits)
Le questionnaire de Dell sur Linux (1146 hits)
DLFP : Le projet OpenOffice.org envoie une lettre ouverte à Dell (179 hits)
DLFP : Dell proposera bien ses ordinateurs avec Linux (315 hits)
> Lire la dépêche (43 commentaires, moyenne: 3,4).
Vous avez demandé le commentaire #814436.




nombre de distrib...
il faut aussi prendre en compte qu'il existe un grand nombre de versions de Vista et cela coûte également cher au constructeur de s'assurer la compatibilité avec les différentes versions.
Axel
[^]Re: nombre de distrib...
Je ne pense pas, car Windows Vista, c'est Windows Vista. Toutes les déclinaisons de Vista sont basées sur le même noyau, etc. De plus, le DVD d'installation est le même. Il n'y a que la couleur de la jaquette et du boitier qui changent, et le numéro de série.
En ce qui concerne les distributions GNU/Linux, la version de noyau n'est p-ê pas la même entre la dernière Ubuntu, la dernière SuSE, la dernière Mandriva ou la dernière Debian ([troll]surtout elle ;-)[/troll]).
Comment marchent le « moinssage » et le « plussage » ?
[^]Re: nombre de distrib...
Ubuntu : 2.6.17
OpenSuSE : 2.6.18
Debian Sarge : 2.4.?
Debian Etch : 2.6.18 (si elle sort cette année)
Mandriva : 2.6.17
Fedora : 2.6.18, puis 2.6.19, et maintenant 2.6.20
Slack : 2.4.?
RHEL 4 : 2.6.9
RHEL 5 : 2.6.18
Novell 10 : 2.6.16
Novell 9 : 2.6.5
Et le tout est incompatible pour les drivers (source et binaire).
Et on ne parle pas des *BSD, Hurd, etc.
[^]Re: nombre de distrib...
Et oui...
Donc ce qu'il faut faire, c'est certifier selon une version du noyau.
Comment marchent le « moinssage » et le « plussage » ?
[^]Re: nombre de distrib...
Ça ne marche pas. Le libre est ainsi fait que chaqu'un peu modifier les sources.
Un 2.6.18 de RHEL n'est pas compatible avec un 2.6.18 de Fedora par exemple. Du moins pour l'ensemble de l'API Linux.
Une possibilité qui est en cours d'exploration :
$ rpm -q --provides kernel-2.6.20-1.2925.fc6.me.3
kernel-drm = 4.3.0
kernel-i686 = 2.6.20-1.2925.fc6.me.3
kernel(kernel) = aa379f785647068167279fe977abbefd49558625
kernel(sound_pci_ac97) = c17bb5b75a98c358fc4e50ba1a68d102c9e3ccf4
kernel(fs_fat) = 4f58d5adf02e04d3f7d074944a7adeea0bcd70c1
kernel(drivers_block) = c51b783b03079f4f3c1d2c0ecea6254075711b1a
kernel(vmlinux) = b615d6a067429c450102a019e2e8c41a2e0cb29a
kernel(drivers_base) = 27d6155f5cc2ce5e616b51df6e4ae7c904688a78
kernel(lib) = fad50b1c96388a20da15215e3eb0fc595a7ddd8d
kernel(drivers) = 129cee6fc81f6285b941097866e3236a676eec23
kernel(init) = 437513b2b973c27fbf9f98de741a800df640ad74
kernel(drivers_parport) = 70cb72012a9fcc732173735cdf2b74c98130f210
kernel(drivers_char_agp) = 09ebcf5f93476391306c3a909e00987a7a82e7e6
kernel(net) = fd29213730f92db025e51e8c8d9bb51e2af70d34
kernel(sound_core) = ae9ca09602944868b4450d6b06981263cf41ebe1
kernel(drivers_usb_core) = 5081cf1425597f9bbd5381f84a76375f38aec463
kernel(arch_i386_power) = de04d9f2cc5bf34387eadbdd5d128e92b2738109
kernel(drivers_md) = a4fca911d31b0bc4505eb47207f9385ee85083e2
kernel(fs) = 5b32252c1f776ba422c8d3b941dd05d95b7a5f3e
kernel(drivers_cdrom) = e5578527961e6012d907b8ef3a6e5bb4bd7a423b
kernel(fs_jbd) = b6061769355ba0e938730d59e3791db98c410d72
kernel(security) = 4623a287a722d1572a2c77f08959479918b025ce
kernel(drivers_char_drm) = efdcf2dcd9f84124eb5788c65ede0a2e3b67ec54
kernel(sound) = 1d34eecea0272060960946bc1e9c5cf600730464
kernel(mm) = 22806249e68eccb01bc4ada405feac6cbf08ff7b
kernel(sound_drivers_mpu401) = 317f2458674d88dd5cffdd0b4300cfd2b49afcad
kernel(drivers_scsi) = 35dc22f4eabd047d22eab4a4fae58492372c9a9f
kernel(crypto) = 67490bf33babdd749c429f908f1a92c072a7264b
kernel(drivers_char) = 61ed37ffddec48898bb33caa3b4873e8ca18cb37
kernel(arch_i386_kernel) = 900c13cdcd280c06d709f507b0df5db7f7580b6a
kernel(drivers_net) = b0491c46092242da7733b63ef6bc2a1f3eba64da
kernel(drivers_ide) = a585e46797485e145c68add8f606b47ca05de1e3
kernel(arch_i386_mm) = bea3d4383eef67713e506859455364b834f4de50
kernel(block) = 73a6b0c62230ab0433f79eb16c1b56c2be5daf98
kernel = 2.6.20-1.2925.fc6.me.3
Ici la liste est "courte" car j'ai un noyau "mini". Sinon ça fait 150 lignes.
On ne passe pas par un numéro de version, mais par un identifiant d'un sous-ensemble de l'api de Linux. Donc un module ne va pas dire "j'ai besoin de Linux 2.6.18", mais il va dire "j'ai besoin de "kernel(drivers_scsi) = 35dc22f4eabd047d22eab4a4fae58492372c9a9f", kernel(...) = "...", etc".
Dans Fedora lorsqu'on met à jours un noyau, il regarde les modules dans le répertoire "extra" et les copies pour la dernière version (/lib/modules/`uname -r`/weak-updates) si l'API n'a pas bougé pour les fonctions utilisées par le module.
Ça marche bien. J'ai par exemple un module qui était pour 2.6.18 et marche pour 2.6.19 et 2.6.20. Ce module utilisait une partie de l'api Linux qui n'a pas bougé entre Linux 2.6.18 et 2.6.20.
Je crois que c'est principalement Red Hat et Novell qui bossent sur ça. Je crois que l'idée est de Novell.
[^]Re: nombre de distrib...
Question :
finalement, le fait que chaque distrib en soit à la version du noyau qui l'arrange, et qu'elle le patch de la manière qui lui plaît, me fait dire qu'il y a là : soit au niveau des distrib, qui ne s'adaptent pas au noyau, soit un problème au niveau du noyau qui n'est pas adapté aux distribs actuelles.
Non ?
http://nikoolinux.zeblog.com/
[^]Re: nombre de distrib...
Ça a été discuté au moins 3000 fois.
Si Novell a envis de backporter des fonctionnalités de Linux 2.6.17 dans leur éprouvé 2.6.16 pourquoi gueuler ? Ils ne le font pas pour faire chier, ils le font car les clients le demandent.
Si Red Hat veut ajouter une fonctionnalité qui n'est pas upstream (gfs par exemple qui longtemps n'était pas upstream) pourquoi l'en empêcher ? Ils ne le font pas pour faire chier, ils le font car les clients le demandent.
Pour RHEL 3, Red Hat avait backporté des fonctionnalité de Linux 2.6 dans Linux 2.4. Il y a eu un mini-scandale. Linus Torvalds a dit que c'était bien puisqu'ils le faisaient pour leurs clients.
C'est la nature même du logiciel libre.
Puis t'as aussi d'autres cas. Par exemple RH9 avait NPTL sur Linux 2.4. Alors que NPTL est upstream que depuis Linux 2.6. Ben ça a permis de mettre au point NPTL avant qu'il soit upstream.
F7 (et peut-être la prochaine Ubuntu) auront la nouvelle pile wifi qui sera upstream pour Linux >= 2.6.22. Ça casse l'API, mais ça permet de fiabiliser la pile avant de la mettre upstream.
[^]Re: nombre de distrib...
Et le tout est incompatible pour les drivers (source et binaire).
Mais bien sur ...
On se demande comment certains drivers externes arrivent a le faire si on t'écoutait.
Certes il y a quelques différences, mais elle reste somme toute minime et on peut assurer une compatibilité source assez facilement.
Ce qui est important, c'est qu'ils valident avec une version de Linux pas trop recente (3 ou 4 versions de retard) por eviter de dependre de fonctionnalité trop récente.
D'ou l'importance d'une distrib pre-installé : le matos est certifié fonctionner avec cette distrib (et donc la version du noyau qui est dedans).
Si tu veux utiliser une autre distrib, à toi de t'assurer que ça fonctionne ou de compiler les drivers qui vont bien.
[+] [^]Re: nombre de distrib...
> Mais bien sur ...
Le monde merveilleux de Linux où il n'y a aucun problème.
Désolé, j'ai eu tord de critiquer Linux.
Il n'y a pas de problème de compatibilité, ni rien, et si les constructeurs de PC ne fournissent pas Linux c'est car ce sont des méchants, c'est car il y a une conspiration mondiale.
Désolé encore.
[^]Re: nombre de distrib...
> > Mais bien sur ...
> Le monde merveilleux de Linux où il n'y a aucun problème.
le monde merveilleux de matiasf qui prend la ligne qui l'arrange pour nier, négliger, oublier toutes les autres...
Windows has no users. It has hostages.
[^]Re: nombre de distrib...
> le monde merveilleux de matiasf
T'as des arguments...
> le monde merveilleux de matiasf qui prend la ligne qui l'arrange pour nier, négliger, oublier toutes les autres...
Très bien je ne vais pas oublier tous le reste.
> On se demande comment certains drivers externes arrivent a le faire si on t'écoutait.
Tu connais un drivers qui marche avec tous les noyaux des distributions de ces 2 dernières années ?
Non. Réduit à une année, c'est toujours non. Prend que les distributions en cours et c'est encore non.
Autre chose, certain distributeur (tous ?) font un contrôle de version et regarde si la version du module est égale à la version du noyau. Si non (ce qui arrive 99 fois sur 100 ) le module n'est pas chargé.
Bien sûr il y a les sources. Pour compiler un module à la volée, il y a dkms. C'est utilisé depuis combien de temps ? Quelques mois, pas pour tout le monde et ça ne résoud pas tous les problèmes. Loins de là.
De plus ce n'est pas supporté upstream.
> Certes il y a quelques différences, mais elle reste somme toute minime et on peut assurer une compatibilité source assez facilement.
Pipo. Une incompatibilité même mineur résulte en un "ça ne mache pas". Exemple "tout con", récement Linux a viré le fichier "config.h". C'est mineur, mais ça donne un "ça ne marche pas".
On ne compte pas les drivers qui doivent être mise à jours à chaque sortie d'un nouveau Linux.
> Ce qui est important, c'est qu'ils valident avec une version de Linux pas trop recente (3 ou 4 versions de retard) por eviter de dependre de fonctionnalité trop récente.
Insuffisant. Linux n'a jamais garanti la compatibilité ascendant. Et dans la pratique il n'y a pas de compatibilité ascendante.
Regarde les log des drivers :
- update to 2.6.18
- update to 2.6.17
- etc...
> Si tu veux utiliser une autre distrib, à toi de t'assurer que ça fonctionne ou de compiler les drivers qui vont bien.
Humm, ça à l'aire super cool pour Madame Michus.
Je ne remet pas en cause le modèle Linux. Mais nier, avec des argements à la con, les problèmes qu'impliquent ce modèle, c'est débile.
J'ai ignoré tes """arguments""" car ils sont crétins.
[^]Re: nombre de distrib...
Et en plus c'est même pas à toi que je répondais...
Apparament tu n'as pas voulu raté de faire une attaque "personnelle" et sans argument.
Je te laisse à ton monde merveilleux de moule.
[^]Re: nombre de distrib...
Debian Sarge, au choix :
- 2.2.25 ;
- 2.4.27 ;
- 2.6.8.
[^]Re: nombre de distrib...
Avec le 2.6.17 et le 2.618 dans le backport, backport qui n'est pas officiel mais presque...
Bref, j'ai 40 machines sous sarge dont des DELL dernières générations pur sata (même le cdrom) et la sarge marche très bien !
[^]Re: nombre de distrib...
Oui mais on parlait des noyaux officiels sur lesquels le support se baserait.
Évidemment avec Debian sarge, le support de Dell serait bien inexistant avec ses dernières machines.
Pour l'instant, ça marche bien chez toi mais qu'adviendra-t-il le jour où ça ne marchera plus ? Tu ne pourras t'en prendre qu'à toi-même. Pardon : ton chef s'en prendra directement à ta personne car le support de Dell ne prendra pas en charge votre problème...
[^]Re: nombre de distrib...
Pourquoi debian est si utilisé, même sur des serveurs en entreprise ?
Je n'utilise JAMAIS le support DELL pour un problème logiciel. Je n'utilise le support que pour un problème matériel.
Pour moi, la solution serait bien plus saine si le constructeur donnait toujours le kit diagnostic permettant de valider tous les composants de sa machine, celui-ci tournant soit sur CDROM, soit sur une partition dédié mais surtout pas dans un OS (par exemple Windows). Pour le support logiciel, les constructeurs devraient être aussi obligé de publier les spécifications de leur composant de base permettant la programmation d'un OS, quel qu'il soit.
Ce n'est pas à DELL de faire le support logiciel de Red-Hat ou de Windows. En pratique, cela marche déjà très mal. Cela ne fait aussi que pousser à des solutions de monopoles. Que DELL contrôle que Windows et d'autres OS marchent sur leur machine me parait normal mais ce n'est pas une raison pour mettre des batons dans les roues des autres solutions.
Et puis le support pour pas mal de boite privé signifie en pratique de ne faire aucune mise à jour. Il faut souvent arracher un accord pour avoir le droit de faire les mises à jour automatique de Windows. J'ai même connu le cas d'une boite qui vend un serveur de contenu tout intégré mais basé en pratique sur une Red-Hat avec un serveur Apache et une partie en Perl. J'ai posé la question des mises à jour ? C'est bien simple, en plusieurs années, ils n'ont eu aucun problème de sécurité et ne savent pas en pratique ce que veut dire mises à jour de sécurité. C'est écrit dans les contrats mais c'est une coquille vide. En moins d'une année sur ma debian de même génération, j'ai vu défiler plusieurs mises à jour de sécurité : noyau, apache, perl...
Bref, le support, tu sais ce que tu payes mais pas toujours ce que tu reçoit. Et le plus souvent, support signifie avoir le droit d'installer les dernières versions du logiciel... Ce n'est pas réellement du support mais plus un système de location-achat.
[^]Re: nombre de distrib...
> Pour moi, la solution serait bien plus saine si le constructeur donnait toujours le kit diagnostic permettant de valider tous les composants de sa machine
> mais surtout pas dans un OS
J'approuve à 100 %. A un moment je me demandais si ça possait un problème, mais apparament pas vraiment.
> Ce n'est pas à DELL de faire le support logiciel de Red-Hat ou de Windows.
Si Dell veut faire du support, ben qu'il fasse du support. Par contre l'achat d'un PC ne doit pas passer obligatoirement par un OS (donc aussi le support de celui ci).
Je ne dis pas l'achat d'un PC au près d'un fournisseur, mais l'achat d'un PC en général.
> Cela ne fait aussi que pousser à des solutions de monopoles.
Je suis toujours très géné par ce type d'affirmation. Aujourd'hui Dell, HP, IBM fournisse du GNU/Linux. Sans compter les petits fournisseurs spécialisés en Linux. S'il y a un nouveau marché, il y a une offre. Les monopoles empêchent la création de nouveau marché. Ce n'est pas globalement le cas ici.
Le problème est pour les petits fournisseurs. Il faut qu'il puisse se fournir en PC sans OS (pour y installer du Linux ou du Win 98...). PC qui serait livré aux petits fournisseurs sans les marques IBM, etc par exemple. Les petits fournisseurs qui n'ont pas les moyens de faire du hardware, doivent avoir accès à du hardware sans OS.
Je pense que le législateur peut faire quelque chose ici même si ce n'est pas évident (par exemple un téléphone portable a un OS).
> Cela ne fait aussi que pousser à des solutions de monopoles.
C'est (fort) possible si celui qui fait l'OS fait aussi le hardware. Typiquement la XBox. Il y a de la demande pour avoir des XBox sans OS (comme c'est la cas pour PS2/3). C'est indiscutable puisqu'il y a Linux pour XBox et déjà peut-être des milliers d'utilisateurs. Mais non seulement MS refuse de fournir la XBox sans OS, mais en plus il refuse l'installation d'un autre OS.
Dans le domaine des consoles, il faudrait tout remettre sur la table. Pour diffuser un jeux sur une console je ne dois pas avoir l'accord du constructeur de la console. Ce n'est pas le cas aujourd'hui et c'est scandaleux. J'ai plus envis de foutre un coup de pied au cul des législateurs ici que pour les PC ou globalement il n'y a pas de problème. Il offre du Linux s'il y a de la demande dans des conditions économiques viables.