Pourquoi Linux n’a-t-il pas de succès sur desktop ? Entretien avec le PDG de Canonical
Pourquoi Linux n’a-t-il pas de succès sur desktop ?
Entretien avec Mark Shuttleworth, fondateur et PDG de Canonical, éditeur d'Ubuntu
Linux est le plus grand projet communautaire dans le monde du développement. S'il est populaire dans de nombreux domaines (serveurs, cloud, mobiles, etc.), sur le marché des PC, il a beaucoup de retard sur ses concurrents Windows et macOS. Actuellement, Linux détient par exemple moins de 3 % de parts de marché d'après les statistiques du baromètre Net Applications. L'adoption de l'OS sur le marché des PC est freinée par de nombreux problèmes, y compris le manque de constructeurs proposant des PC avec Linux préinstallé ; le support des pilotes et des logiciels propriétaires ; des interfaces utilisateur que les gens trouvent parfois très basiques ; ou encore le problème de fragmentation de l'écosystème. Pour Linus Torvalds en tout cas, la fragmentation est l'un des principaux freins à l'adoption de Linux sur desktop.
S'exprimant lors d'un entretien sur l'avenir de Linux, Mark Shuttleworth, fondateur et PDG de Canonical (éditeur d'Ubuntu) a pour sa part affirmé que « le plus gros problème est que nous n'avons rien inventé dans Linux qui soit profondément, puissamment en avance sur son temps ». Il salue au passage les développeurs de Chrome OS qui avaient « une vision très futuriste du desktop, une extension du Web ». Ce type de vision, on ne le trouve pas dans le monde du logiciel libre, selon Mark Shuttleworth, car la communauté du logiciel libre essaierait plus de faire des choses qui ressemblent à ce qui existe déjà. Ce qui conduit à des forks et fragmentations. Il exprime également son regret sur le projet Unity dont le développement a été arrêté à cause de l'opposition de la communauté.
Extrait de l'interview avec le PDG de Canonical
Q- Voyez-vous toujours un espoir pour Linux sur desktop ?
Mark Shuttleworth : Je pense que pour le moment le public est un public d'ingénieurs ... La légère difficulté ici est que les ingénieurs aiment changer les choses, ils ont aussi des opinions et ils ne veulent pas la même chose que tout le monde. Cela n'aide donc pas beaucoup... J'ai appris cette leçon aux jours d'Unity. Je pensais que nous faisions un très beau travail, mais les gens n'aimaient pas que cela leur soit imposé. Alors, je me suis dit : supportons l’environnement Gnome, supportons l’environnement KDE, supportons l’environnement Mate. Cela donne aux développeurs la liberté de choisir toutes ces choses...
Q- Linus a déclaré que l'un des principaux problèmes de Linux sur desktop est la fragmentation. Pensez-vous que Linux sur desktop aurait pu réussir s'il avait été traité comme une plateforme unique pour que les entreprises considèrent Linux comme une plateforme unique, et non 20 000 distributions ?
Mark Shuttleworth : Je pense que c'est possible, mais le seul moyen d'y parvenir est si vous avez créé Linux afin que, légalement, une seule personne puisse le faire et ce ne serait pas Linux. Je pense que le plus gros problème est que nous n'avons rien inventé dans Linux qui soit profondément, puissamment en avance sur son temps ... J'aime ce que les gars de Chrome OS font parce qu'il y avait une vision très futuriste du bureau, une extension du Web. Et donc, ils méritent essentiellement leur succès, car ils étaient prêts à créer quelque chose qui n’existait pas dans un monde où, pour la plupart des gens, un OS de bureau ressemblait à Windows.
Si dans la communauté du logiciel libre, nous ne nous permettons que de parler de choses qui ressemblent à quelque chose qui existe déjà, alors nous nous définissons en quelque sorte comme une série de forks et de fragmentations. C’est quelque chose que j’ai trouvé très difficile dans Unity parce que je pensais que nous avions exprimé une vision de la convergence et je pense que cela va se produire. Je pense qu'au moment où iOS et macOS allaient converger, nous aurions déjà 10 ans d'avance, mais la communauté ne nous a pas laissé faire, ce qui est un peu fou...
Source : YouTube
:fleche: Avez-vous toujours espoir que Linux aura du succès sur le marché des PC ?
:fleche: Quel est le principal problème avec Linux sur desktop ?
Voir aussi :
:fleche: Si Linux a de la peine à s'imposer sur le desktop c'est à cause de la fragmentation de l'écosystème, d'après Linus Torvalds
:fleche: « Linux a échoué sur le Desktop » pour le créateur de GNOME, un avis tranché qui divise la communauté open source
:fleche: 2017 est officiellement l'année de Linux desktop selon un utilisateur de macOS : le patron de la Fondation Linux, quel message aux fans de Linux ?
Il faudrait peut-être unifier et valider certaines libs fondamentales pour les dev multi-plateformes
Bjr à vous,
Je fais du dev Lazarus sur Windows et Linux (dont Raspberry)
Je travaille actuellement sur le dialogue entre un PC (ou un Raspberry) et un appareil Bluetooth
Sous Windows, relativement peu de problèmes. Dès que le pilote Bluetooth fournit un port série, je peux travailler sur le port attribué.
Sous Linux, c'est galère, larmes de sang, cauchemar, et ce pour un résultat non reproductible et incertain.
Parmi les épreuves qui attendent le dev Lazarus:
- Le wrapper fourni par http://wiki.lazarus.freepascal.org/Bluetooth.pas manque d'exemples
- Les exemples fournis ne compilent pas / ne fonctionnent pas. L'exemple fourni me compile pas (erreur 'Error linking ...)
Pour des unités fondamentales, cette situation est inadmissible vu l'ancienneté de ces projets
- Documentation soit absente soit non fonctionnelle soit imbittable
- Des bidouilles pénibles et incertaines accaparent le temps du développeur, qui a autre chose à faire que de la prog système
Exemple pour un device Bluetooth:
sudo hcitool scan
puis
sudo rfcomm bind /dev/rfcomm1 <adresse MAC de ton device au format AA:BB:CCD:EE:FF> 1
puis
sudo rfcomm
puis:
sudo picocom -c /dev/rfcomm1
puis ...
Juste invivable. C'est du bricolage, pas du dev.
Résultat: je vais laisser tomber et passer sur un terminal durci Panasonic CF19 sous W7
Le dev d'application ne doit pas être encombré par des considérations de prog système. Les API qu'on lui fournit doivent être faciles d'emploi, standardisées, fiables à 100%
A quand une autorité de certification des librairies fondamentales ?
A quand des API unifiées, testées, fiables, avec une reproductibilité de 100% quelle que soit la plateforme ?
Tant que ce genre de pbs, qui ne devrait plus avoir lieu d'être étant donné l'ancienneté des standards concernés, subsistera, la migration vers Linux ne se fera jamais.
D'ailleurs, j'ai un pb de non reconnaissance de casque Bluetooth chez un ami que j'ai doté en Ubuntu. Nous en sommes à n essais mais on a jeté l'éponge
Voici un condensé du process:
- Mon PC sous W10 est très lent et il faut le nettoyer
- Pas de pb. Je te mets Xubuntu
Et un Xubuntu sur son poste, un
Quelque temps après:
- Mon nouveau casque Bluetooth n'est pas reconnu,
- Bon, on va voir çà.
... Bidouilles diverses et avariées ... Mon pote s'impatiente
- Alors çà marche, oui ou non ?
- Cà devrait 'normalement'. Je te fais un script Bash avec son lanceur
Effectivement, çà marche très bien avec le script. Pb: il faut l'exécuter en root à chaque démarrage.
- Je vois, mais même si tu as créé un lanceur sur le bureau, je ne me rappelle jamais du mot de passe, et çà me bloque. De plus, si je change de matos, il faudra reparamétrer. Tout ceci me gonfle, j'ai une licence valide de Windows 7 Pro.
On casse l'installation de Xubuntu et on réinstalle Windows 7. Réactivation OK, matos reconnu immédiatement, connexion établie avec succès du premier coup. Mon pote est très satisfait, il retrouve un environnement familier, çà marche du premier coup.
De mon côté, j'ai les configurations suivantes auxquelle j'associe un lasermètre spéléo DistoX2 fournissant un port série:
1. Un PDA sous Win Mobile 6.1, muni du logiciel PocketTopo (paperless.bheeb.ch ). Reconnaissance OK, connexion OK, fonctionnement OK
2. Des PC sous Windows 7 et Windows 10, munis de PocketTopo. Reconnaissance OK, connexion OK, fonctionnement OK
3. Mêmes PC mais avec GHTopo, développé en Lazarus. Avec le TLazSerial de Jurassik Pork, çà fonctionne très bien
4. Un PC sous Xubuntu, avec GHTopo compilé sous Linux: Reconnaissance OK (mais procédure fastidieuse), connexion OK. Du côté de GHTopo, pas mal d'adaptations à faire. Ce n'est pas encore fonctionnel pour aller sur le terrain
5. Un Raspberry Pi, avec un Lazarus ad hoc. GHTopo compile sans problème, TLazSerial n'y a pas été porté. Je me tourne vers le wrapper bluetooth.pas. Dès que j'utilise les fonctions hci_* du wrapper dans GHTopo, erreur du linker. Donc, je suis bloqué. La solution RPI n'est pas envisageable en l'état.
Devinez la solution qui va sous terre. Lors d'une sortie topographique dans un gouffre, on me dit:
- C'est bien ta démarche de privilégier le libre, mais pourquoi tu utilises un PocketPC sous Win Mobile ou un PC sous Windows 7 ?
- Parce que je suis spéléologue avant d'être dev. Aujourd'hui, on fait de la prod topo et j'ai un résultat à rendre après la sortie. Je n'ai pas à batailler avec un système capricieux dans le froid et l'humidité donc je prends les solutions qui marchent.
On a vu ensemble lors d'une sortie en carrière qu'il a fallu taper des lignes de commande avec le PC Linux. Ici, nous sommes dans un gouffre; il y a un puits de 65 mètres à topographier et il y a une seule voie. Tu te vois à un fractionnement en train de taper des lignes de commande, en plus de la séance topo, alors que 8 personnes attendent derrière ?
Les pilotes, et leur installation simplifiée
C'est la chose la plus élémentaire qui m'a à chaque fois fait fuir Linux lorsque j'ai tenté de l'utiliser.
Un matériel récent, par exemple une imprimante Wifi (lorsqu'il y a quelques années elles sont sorties), et je ne trouvais aucun pilote adapté, et en plus il fallait passer en ligne de commande. Quand on débarque de Windows ou MacOs on est un peu perdu. Il n'y a donc pas d'entrée facile dans le monde de Linux pour cette simple raison.
Car sinon, l'offre logicielle, l'ergonomie, l'interface, et même les panneaux de configurations sont tous suffisamment développés pour 90% des besoins. Mais quand je vois encore beaucoup de Webcam qui ne fonctionnent pas, ou qui ne sont pas simples à activer, et cette façon de présenter les entrées sorties comme des répertoires, c'est assez déstabilisant.
Donc quand on aura un :
- Gestionnaire de périphériques graphique visuel et universel,
- des ports nommés de manière transparente (COM1 COM2, USB, PTR, BLUETOOH etc, comme ailleurs),
- ou à défaut un emplacement universel ou les retrouver qui ne dépend pas des caprices ou particularités de telle ou telle distro, quand on aura par exemple une convention de nommage des répertoires totalement explicites y compris pour un néophyte (\programs pour les logiciels \drivers pour les pilotes \devices\out pour les periph de sortie ... mais bon c'est un débat ensuite qui sort du contexte d'adoption. Ceci dit pour un néophyte qu'on oblige à aller dans le Bash pour installer son imprimante ou sa webcam, il faudrait faire plus explicite, à défaut d'interface graphique de gestion de matériel et d'assistants d'installations intuitifs pour nos matériels.
- et une systématisation des drivers génériques universels (non dépendants de telle ou telle distro ou de tel ou tel environnement graphique, ni de tel ou tel répertoire spécifique), pour tout matériel qui sort sur le marché.
Bref, pour moi le seul frein qui a toujours freiné l'adoption des utilisateurs "desktop" de linux ce sont les drivers, et la capacité d'un utilisateur qui découvre l'OS, et qui installe OpenOffice, de pouvoir imprimer tout simplement son texte !
Simple ! Basique !