Back

OS et langages, pensées noires du jour

2012-03-07

L’utilisateur lambda, c’est tout à fait normal qu’il se tourne vers les solutions privatrices que tout le monde connaît (pour ne pas les citer, Windows et Mac OS X). Et pourquoi ? Parce que ces systèmes sont meilleurs, d’un point de vue technique et fonctionnel. En effet, les systèmes d’exploitation alternatifs libres souffrent de défauts majeurs, que je tenterai de développer ici :

Pour résumer vite fait : les systèmes d’exploitation aujourd’hui sont soit bordéliques et inadaptés au grand public, soit privateurs. Dans un tel contexte, ce n’est pas tout à fait anormal que la majorité des utilisateurs renoncent à leurs libertés pour utiliser un système qui leur convient mieux.

Développons un peu, point par point :

Les problèmes

C’est le bordel

Techniquement

Oui, c’est le bordel du côté des systèmes GNU/Linux. Déjà, il y a une infinité de distributions, toutes avec des outils différents pour faire, au final, globalement la même chose. Par exemple :

Mais considérons que, tant que les distributions restent cohérentes en elles-mêmes sur ces points, ça peut encore aller - d’autant plus que chaque distribution peut avoir un objectif précis, qui ne peut être réalisé qu’à l’aide d’un outil en particulier. En fait, il y a beaucoup plus gênant :

Personnellement, j’ai déjà voulu coder des “petites” applications de bureau, et j’étais complètement perdu dans le choix du langage de programmation et des bibliothèques et toolkits à utiliser, tant bien que j’ai la plupart du temps abandonné mon projet avant même de le commencer.

Dans la communauté

Globalement, j’aurai tendance à dire que dans le mouvement du logiciel libre, le développeur lambda tendance à coder son projet chacun dans son coin, en suivant ses tendances personnelles, ce qui de toute évidence n’aide pas à résoudre les problèmes ci-dessus.

Il serait beaucoup plus intéressant que, au lieu de vouloir promouvoir chacun son projet et sa manière de faire, les développeurs de tous bords aient une volonté commune d’avancer vers un idéal, un système qui ait une certaine forme de cohérence. Cela n’implique pas forcément que l’on impose une hiérarchie aux développeurs, c’est plutôt une prise de conscience globale, qui permettrait que chacun réfléchisse à ce qui est mieux pour la globalité, et oriente son travail dans cette direction là, plutôt que de partir chacun dans son coin.

C’est pas pratique, pas fonctionnel

Un exemple très simple devrait vous permettre de comprendre globalement où je veux en venir : où sont, mais bordel de merde où sont les logiciels de reconnaissance vocale pour Linux ? Ah ben non, il n’y en a pas. Pourtant, c’est sacrément utile, dans certains cas. En tout cas, l’utilisateur lambda, lui, il fait de la bureautique, et selon ses activités il peut être très content, voir même avoir besoin, de pouvoir dicter ses documents, pour toutes les raisons que vous pouvez imaginer. (Je connais plusieurs personnes qui ne pourraient pas vraiment se passer de ça).

Je n’ai plus d’idées pour développer ce point. Veuillez m’en excuser.

Unix, ça suffit

Moi je dis, regardez : le système le plus populaire, et qui semble largement satisfaire (quand même hein, il faut le dire!), n’est pas basé sur Unix. Oui, c’est pour moi une preuve flagrante qu’Unix n’est peut-être tout simplement pas adapté à l’utilisateur lambda. Ou en tout cas, sous sa forme actuelle de GNU/Linux, il ne l’est pas. Remarquons quand même qu’Apple a réussi à en faire quelque chose d’orienté grand-public, et franchement je pense qu’ils ont réussi.

En fait, le problème vient essentiellement du fait qu’Unix, encore une fois, est multiple : il y a plein de systèmes d’init, plein d’interpréteurs de commandes différents, plein d’implémentations de la libc qui varient sur des poins fondamentaux, mais qui au final offrent nombre de différences parfois subtiles dans les interfaces offertes au programmeur, obligeant l’utilisation d’un système appelé autotools, qui alourdit considérablement le processus de développement d’applications.

En fait, il faut effectivement admettre que jeter tout Unix à la poubelle et repartir sur autre chose, ça risque d’être très difficile. On peut peut-être s’en contenter, mais il faut voir aussi où sont les problèmes, et essayer de faire avec pour construire, encore une fois, quelque chose de cohérent.

Programmer aujourd’hui : pas de langage satisfaisant

Les gens codent mal

Il y a deux types de programmeurs, et j’aurai tendance à les différencier selon la génération à laquelle ils appartiennent :

En fait, l’augmentation exponentielle des performances des systèmes conduit à un certain laisser-aller de la part des développeurs, se disant que s’ils ne codent pas bien, ce n’est pas grave parce qu’un algorithme en O(n²) s’exécutera aujourd’hui (sur des petits ensembles de données) aussi rapidement qu’un algorithme en O(n log n) sur du matériel d’il y a 10 ou 20 ans. En fait, je crois même qu’il y a une portion de programmeurs qui ne s’en rendent même pas compte, tout simplement car comme ils ne voient pas la lenteur de leurs programmes (ou alors celle-ci leur parait négligeable), ils vont rester sur un algorithme inefficace, se disant que ça ira bien.

De manière générale, on peut donc dire que les gens qui codent ne codent pas forcément bien, ce qui conduit au principe suivant, bien connu de tous (ou pas ?) : les logiciels deviennent plus lents (bloatware, mal codés, etc.) plus vite que les ordinateurs deviennent plus performants et plus rapides.

En toute logique, les applications que l’on avait déjà il y a 20 ans (mail, traitement de texte, etc.) devraient être soit vraiment vraiment plus rapides, soit vraiment vraiment plus riches en fonctionnalités aujourd’hui qu’à l’époque. En pratique, certes on a plus de fonctionnalité, mais pas forcément tant que ça, et surtout on n’a pratiquement pas gagné en vitesse d’exécution de ces programmes. C’est un peu problématique, vous en conviendrez.

Quel langage utiliser ?

En fait, le problème vient aussi des langages de programmation que nous avons à disposition. Globalement, il y a deux options :

C’est pourquoi je suis sidéré aujourd’hui de voir que l’on a écrit Tribler, un client BitTorrent aux fonctionnalités certes révolutionnaires, mais en python quoi, bordel de merde ! J’avais à peine lancé le logiciel et effectué quelques recherches que celui-ci me bouffait quelques centaines de Mo de RAM. C’est absolument inadmissible, je n’ai que 2Go moi ! Au secours !

Dans le même genre, j’ai essayé plein de lecteurs de musique, et finalement la plupart étant écrits effectivement en Python, ils avaient tendance à ramer (un peu) quant à la gestion de ma bibliothèque, qui n’est pourtant pas si grosse que ça. (Enfin si, mais même : c’est normalement le propre de ces logiciels que de savoir gérer une collection importante de musique. Je me trompe ?). Mais ça dépend des logiciels, certains sont mal écrits, d’autres pas si mal, et j’ai plus ou moins fini par trouver une solution satisfaisante. Mais je me suis fait chier. Sous Windows, j’aurai tout simplement utilisé le Windows Media Player, et sous Mac OS X je me serai contenté d’iTunes, qui niveau fonctionnalités et vitesse d’exécution sont franchement satisfaisant, le principal défaut étant celui que vous êtes tous là à me pointer du doit - ce sont des logiciels privateurs.

Mais les fautifs dans l’histoire, ce sont peut-être les langages de programmation eux-même : il est difficile (voir impossible, et même s’il existait, alors il est bien trop peu connu) de trouver un langage qui réunisse les avantages suivants :

Les conséquences

Du côté du grand public, vu que de toute évidence les logiciels libres ne sont pas prêts, il est tout à fait naturel que les utilisateurs préfèrent les solutions privatrices bien connues de tous. Pourtant, le but du logiciel libre n’était-il pas de permettre à tout un chacun (même les plus incompétents et imperméables à l’informatique) de reprendre le contrôle de son PC ? J’aurai tendance à dire : RMS fail. Mais ça n’engage que moi (comme tout cet article, d’ailleurs).

Du côté des développeurs, l’esprit qui règne dans la communauté des logiciels libre n’est pas vraiment satisfaisant, comme je l’ai déjà dit, chacun voulant avancer dans son coin à faire son projet avec ses idées et la méthode qui lui parait à lui la plus satisfaisante (parfois d’un point de vue qui ne prend en compte que ce qu’il connaît déjà, donc voilà quoi). Il en résulte donc que pour l’instant, on est dans un plutôt gros merdier (c’est franchement pas très agréable) qui n’a pas l’air d’avancer beaucoup.

Les solutions

Déjà, il faudrait que tout le monde se rende compte qu’il y a un problème. On pourrait en discuter un peu sérieusement, plutôt que de troller (enfin ceci dit je n’ai pas dit que troller c’est mal, d’ailleurs je suis probablement moi-même en train de troller, et c’est une bonne chose car ça me permet de dire ce que j’en pense. Là où il y a un problème, c’est quand le débat n’avance pas et qu’il en résulte de la merde).

Déjà, moi je pense qu’il faudrait que tout le monde s’impose de coder bien, proprement, avec rigueur, etc. Le problème, c’est que parmi les gens que je fréquente (comprendre : parmi les autres élèves de prépa maths/physique), même parmi ceux qui s’intéressent à l’informatique et à la programmation, aucun ne semble avoir le goût du code bien écrit, ni la clarté d’esprit requise pour coder bien. C’est dommage. Et ce n’est pas notre prof d’informatique qui aide à développer ça. C’est dommage aussi.

Sinon, sur un ton plus radical, et c’est ce que j’aurai bien envie de faire - malheureusement, tout seul je ne vais pas aller bien loin - il y aurait la possibilité de faire table rase et de concevoir un nouveau système d’exploitation, basé sur un nouveau langage de programmation (ou deux éventuellement, si on veut séparer le vraiment bas niveau, c’est à dire le noyau, les périphériques, et les systèmes de fichiers, et le moins bas niveau, ce qui semble effectivement logique ; mais essentiellement toutes les applications seraient alors écrites avec le langage de haut niveau, qui sera de toute façon totalement optimisé aussi bien pour les performances que la facilité d’écriture), le tout étant planifié à l’avance pour avoir une cohésion globale, c’est à dire qu’il faudrait, à défaut d’imposer le totalitarisme au développeur, au moins débattre et décider une fois pour toute de comment le système sera organisé, et ensuite gérer le projet de manière à n’accepter que le code qui suit cette organisation - et accessoirement, qui satisfait des critères de bien-écriture que l’on définira aussi à ce moment. Mais c’est peut-être un peu utopique (voir beaucoup), donc voilà, globalement je ne sais pas si on peut faire grand chose.