• [^] # Re: Et alors ?

    Posté par . En réponse au journal Contributions à Gnome. Évalué à 5.

    Nous nous trouvons dans une situation paradoxale. Le nombre de bêta-testeurs sous Windows [...] approche du million [...]. Parallèlement à cela, nous avons beaucoup de mal à avoir des bêta testeurs sous Linux en grande partie parce que nos canaux de communication habituels sont remplacés par ceux de la distro lors de l'empaquetage.

    Et dans les premiers commentaires, on parle de la difficulté d'installer des programmers tiers sous Linux (hors du système de paquets de sa distribution). Je pense que Zenitram a entièrement raison de critiquer Linux sur ce point.

    Et non, la solution n'est pas de dire « Vous n'avez qu'à faire un paquet pour chaque distribution ». Linux, c'est 1% des machines de bureau. Windows, 92% et Mac 6%. Ça veut dire qu'avec une version Windows et une version Mac, les développeurs touchent environ 98% du marché. Certains ne se soucient même pas de mac.

    C'est déjà pas étonnant que la majorité des éditeurs/développeurs ne s'intéressent pas au 1% de Linux. Mais en plus, on a trouvé le moyen d'en rajouter ! Linux est sous-divisé entre deb, rpm et d'autres formats de paquets. Oh, et les distributions qui utilisent le même format trouvent le moyen d'être incompatibles, par exemple parce qu'elles donnent pas toutes le même nom de paquet à une librairie ! Typiquement : libphonon4 sur une, liqt4-phonon sur une autre, lib-qt-phonon-4 sur une autre...

    Il y a pourtant des pistes qui sont ouvertes. Si packagekit se démocratise, il permettra de s'affranchir de l'enfer des dépendances non compatibles. Un développeur qui veut faire un installateur pour son programme pourrait dire à packagekit : « Je veux phonon en version 4 ». À packagekit de se démerder avec le gestionnaire de paquet sous-jacent pour l'installer.

    Une autre piste intéressante me semble être fatelf. L'idée c'est d'inclure dans un seul exécutable linux (elf) les exécutables pour plusieurs architectures. Un même binaire pourrait alors marcher aussi bien sous i386 que amd64, ia64, arm ou tout autre architecture pouvant devenir populaire dans le futur.

    Il y a aussi des projets en place comme LSB et freedesktop. Parce qu'on pourrait aussi parler des histoires de toolkit gtk/qt-kde qui amènent des bidouillages comme kgtk.

    Il faut regarder les choses en face : jusqu'ici, la majeure partie des entreprises qui s'intéressent à Linux s'y intéressent en grande majorité pour le mettre sur un serveur. Et même si Debian a une philosophie de système universel, son fonctionnement actuel la rend intéressante pour le serveur, beaucoup moins pour le bureau.

    Bien sûr, Il y a des exceptions comme Canonical (non bénéficiaire), Mandriva (menacée de faillite), paradoxalement Novell même si ses bénéfices sont sur le serveur, et aussi maintenant ce qui touche autour de l'embarqué (comme Google/android/chromeos, Nokia/qt/meego...). C'est d'ailleurs la grande opportunité de Linux dans le futur : réussir le virage de l'informatique mobile.

    M'enfin le résultat, c'est que la majeure partie des investissements et développements améliorent le côté serveur. Alors pour ça, Linux déchire : performances, stabilité, sécurité, capacités réseau... Très bien. Mais côté bureau, c'est toujours la misère. La misère pour les toolkit (ah, en 10 ans on a eu le copier-coller commun quand même), la misère pour le son, la misère pour la 3D, et la misère pour installer des programmes tiers.