OS & langages : pensées noires du jour

critique, idées, informatique

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 :

  • Trop d’API (par exemple : l’audio sous Linux), trop de frameworks (ex: QT, GTK, etc.), qui ne travaillent pas de concert
  • Manque de stabilité, manque de prise en charge de certains matériels (sont concernés : certains BSD, Haiku (qui est pourtant un bel effort !), …)
  • Peut-être qu’Unix n’est tout simplement pas adapté pour servir l’utilisateur lambda ; peut-être qu’Unix se fait vieux, et qu’il faudrait passer à autre chose
  • Un manque de direction généralisée laisse les développeurs en vadrouille, chacun sur son projet, à sa manière, sans s’imposer nécessairement les directives élémentaires de la bonne programmation (comprendre : les gens codent comme des pieds)
  • Des langages inadaptés
  • Pour l’utilisateur lambda, il en résulte un manque de fonctionnalités que l’on pourrait qualifier d’ “élémentaires”, ou presque

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 :

  • Plein de gestionnaires de paquets, qui offrent sensiblement les mêmes fonctionnalités (juste avec des lignes de commande différentes, et plus ou moins optimisés – duh)
  • Plein de mécanismes d’init différents (System V, upstart, systemd, openrc (gentoo), et j’en passe sûrement)

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 :

  • Il y a, par exemple, 42 façons différentes de programmer une application qui utilise les périphériques audio (clivage ALSA/OSS, utilisation ou non de PulseAudio, quelle bibliothèque choisir, etc.). C’est sûrement le cas aussi avec d’autres API.
  • Il y a parfois un gros paquet de bibliothèques qui font la même chose (exemple : gstreamer/xine/mplayer/vlc/etc…), et selon les applications que l’on utilise, on est en général obligé d’en installer plein de différentes.
  • Par rapport aux toolkit graphiques, on a le traditionnel clivage GTK/QT, on a des frameworks qui se rajoutent là dessus (les kdelibs par exemple), tant bien que le programmeur quelconque qui veut coder une application de bureau pour son système GNU/Linux sera obligé de choisir parmi plein de bibliothèques ayant toutes des avantages et des inconvénients, souffrant en général de problèmes de compatibilité, et étant obligé, pour bénéficier de certaines facilités, de lier son application à un environnement de bureau en particulier, obligeant encore une fois l’utilisateur à installer plein de bibliothèques juste pour une application (par exemple : si ktorrent ne dépendait pas de plein de morceaux de KDE, je m’en servirait probablement).

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 :

  • Les vieux de la veille, qui ont grandi avec du Basic sur commodore 64, qui codent en C, à gérer tous les détails à la main, pour coder au final des applications efficaces et bien codées en général, et ça c’est bien.
  • Les petits jeunes, qui ont grandi avec du PHP/HTML/Javascript, du Python, du Ruby, du Caml, et plein d’autres langages de haut-niveau, et qui n’ont plus vraiment le sens du code bien écrit, qui ont tendance à aller à la facilité, etc.
  • Enfin, il y a les ingénieurs certifiés (lol), qui sont spécialisés par exemple en Java, et qui ne savent utiliser que certains frameworks très spécifiques auxquels ils ont été formés. Ces gens sont aussi appelés pisseurs de code, travaillent en général pour une entreprise qui a besoin d’un logiciel pour des besoins spécifiques, et n’ont pas vraiment non plus le sens du code bien écrit.

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 :

  • Coder en C (ou en C++ éventuellement), ce qui implique de se faire chier à un certain degré dès que l’on veut coder des trucs un peu complexes
  • Coder dans un langage interprété, par exemple Python, qui offre plein d’outils et de bibliothèques pour programmer simplement des applications assez complexes, mais finalement Python étant un langage interprété il n’est pas adapté non plus pour des projets qui doivent traiter une masse de données.

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 :

  • Rapidité d’exécution (ce qui implique globalement qu’il soit compilé, éventuellement JIT)
  • Retour rapide pour le développeur (temps de compilation nul ou négligeable, ce qui n’est pas le cas avec C, C++, Vala, etc.)
  • Facilité d’écriture (orienté objet, ramasse-miettes, librairie standard fournie, syntaxe pas trop lourde). Remarquez que cela n’implique pas pour moi que le langage n’est pas typé, au contraire, je défend le typage fort pour imposer un peu de rigueur chez le programmeur. Mais même, on peut faire un langage qui soit plus facile à utiliser tout en étant assez fortement typé.
  • Possibilité de s’intégrer avec la majorité des bibliothèques C ou C++ dont tout le monde à besoin (GTK ou QT, bibliothèques multimédia, etc.)

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.