Combien faudra-t-il d’ArkOS pour que le monde du libre ait – enfin – une prise de conscience ?

Je l’ai appris via un billet de Carl Chenet sur le réseau social encore plus fantômatique que google plus, à savoir la framasphere*, qui reprenait un article de Phoronix.

Vous ne connaissiez pas ArkOS ? Moi non plus jusqu’à aujourd’hui. Pour tout dire, je ne m’intéressais pas à des projets proposant des distributions pour l’auto-hébergement, n’ayant pas ni la bande passante ni le matériel nécessaire pour l’envisager.

Même si j’ai lu l’excellent livre de Thuban dont la version 3 est disponible depuis le 22 avril 2017, et que je connaissais déjà de nom le projet yunohost, j’avoue que l’annonce de l’abandon du projet ArkOS ne m’étonne qu’à moitié.

En effet, on tombe encore une fois dans le même travers : avoir les yeux plus gros que le ventre et dans son corollaire… Ignorer l’existant et réinventer encore une fois la roue.

Nombre de projets – que ce soit des distributions GNU/Linux ou encore des logiciels de plus haut niveau comme des lecteurs de vidéo, des navigateurs (qui se résument 95% du temps à une interface enrobant qtwebkit ou webkitgtk) – sont sous-alimentés en terme de nombre de développeurs pouvant s’en occuper.

Résultat des courses ? On se retrouve avec des dizaines de projets laissés plus ou moins à l’abandon avec les utilisateurs se retrouvant le bec dans l’eau, faute d’avoir misé sur le mauvais cheval 🙁

Je sais que certaines personnes vont m’intimer l’ordre de fermer mon clapet – dans des termes largement moins courtois – mais il faut le dire ainsi : nombre de projets dans le libre sont condamnés par un manque de responsabilité des développeurs enfermés dans un individualisme mâtiné d’une version extrémisée des saints canons de la FSF dont on attend toujours le noyau GNU/Hurd soit dit en passant. Désolé, je nettoyais le clavier et le coup est parti tout seul 🙂

Plus j’observe les projets du logiciel, plus je vois une tendance à se disperser, comme s’il fallait démultiplier les efforts à l’infini pour les mêmes outils. Il y a d’autres exemples récents de prises de conscience comme Canonical qui a débranché la prise du projet Unity8 et par la suite de Mir.

Cela n’a pas empếché des personnes de reprendre le code d’Unity 8. Qui parie que dans 6 à 12 mois, le projet sera tombé dans les oubliettes de l’histoire du logiciel libre ?

Dans ce phénomène de dispersion, je rajouterai le projet Solus qui a décidé de produire une image ISO avec une version assez maintenable de Gnome. J’avoue que je n’ai pas vraiment compris le pourquoi d’une telle saveur, alors que le projet a annoncé que la version 11 de Budgie-Desktop se baserait sur QT5…

Je pense faire un billet sur la nouvelle version des images ISO du Solus Project dans le courant de la semaine du 24 avril 2017.

Une volonté de s’attirer quelques utilisateurs de plus ? Il n’aurait pas été plus bénéfique de faire grossir la logithèque un peu maigrichonne du projet avant d’ajouter un nouvel environnement ?

Enfin, je dis ça, mais je dis rien. Je dois être particulièrement bête pour penser que l’union fait la force et que mutualiser les efforts permettrait de faire avancer le schmilblick et faire monter d’un cran la qualité des logiciels libres, du moins en dehors du monde conquis – pour le moment ? – des serveurs.

S’occuper des interfaces pour les utilisateurs lambda, c’est dégradant ? Désolé de poser la question, mais quand on voit le nombre de projets qui ont des interfaces dont l’ergonomie est repoussante, on se demande s’il n’y aurait pas besoin de se concentrer sur ce point précis, au lieu de vouloir réinventer une nouvelle fois la roue dans un domaine plus technique, comme les gestionnaires de paquets, un système d’initialisation ou une bibliothèque graphique.

Dans une vidéo, j’ai parlé de mes débuts avec GNU/Linux en 1996… Attention, ça pique les yeux par moment 😉

D’énormes progrès ont été faits sur les tripes, c’est incontestable. Mais si maintenant, les développeurs se regroupaient, unissaient leurs forces et s’occupaient de la façade pour changer ?

Je sais très bien que je ne serais pas entendu, mais au moins, ça fait du bien de l’écrire 🙂

Allez, bonne journée !

25 réflexions sur « Combien faudra-t-il d’ArkOS pour que le monde du libre ait – enfin – une prise de conscience ? »

  2. « T’as gueule!! »
    ça c’est la réponse que beaucoup te feront, je la faite pour le faire gagner du temps….

    Sinon je suis globalement d’accord il y a beaucoup trop de projet dans le monde du libre, le pire étant que tout le monde crittique tout le monde, tout le monde parle en même temps sans écouté l’autre., on se retrouve avec des projet doublon qui se font concurrence.
    L’exemple de SolusOs est flagrant ils ont commencé avec une interface qui à mon humble avisa de bonnes idées qui méritent d’être amélioré. Et là ils ont commencé à sortir une version mate maintenant une version gnome demain une plasma puis une xfce….

  3. En tant que contributeur et utilisateur de Solus, je peux répondre à ta question concernant l’ISO Gnome: En fait toute l’infrastructure Gnome était déjà en place et Gnome Shell était d’ailleurs disponible dans les « applications tierces ».
    Donc proposer Gnome en tant que saveur officielle n’a pas nécessité beaucoup d’efforts : un gros weekend (incluant la mise à jour de la plupart des composants vers la version 3.24). Ainsi que quelques jours pour la mise à jour de Budgie et les tests.

    Et la réécriture de Budgie en Qt5 ne change rien, il s’agit d’un choix des développeurs qui (entre autre rencontraient trop de problèmes lors des mises à jour de GTK). Les applications proposées avec le Bureau Budgie continueront à être celles de Gnome.

    2. Et un grincheux qui passe par là va se demander s’il n’y a pas un peu trop de monde dans la rubrique « environnement basé sur Gnome »…
      Ensuite reste plus qu’à savoir qui est vraiment de trop. Budgie ? Cinnamon ? Mate ? Gnome 3 ? etc. etc.
      La question n’est pas de savoir si tel ou tel nouveau fork apporte qqch. La question est de savoir si ce qqch qui est apporté en plus vaut la peine, par rapport à la dispersion que ça génère.

      1. La dispersion est aussi une source de diversité et d’innovation… C’est l’essence même du logiciel libre (en tout cas des licences GPL).

        Je pense que dans le cas de cet article et des commentaires qui en découlent, on condamne cette dispersion à tort : Lorsque la dispersion apporte quelque chose de neuf et/ou remonte certaines modifications aux projets parents, ce n’est pas négatif même si on peut souvent regretter le manque de synergies. Là où la dispersion est néfaste selon moi c’est lorsqu’elle n’apporte rien par exemple pour rester dans la thématique de ce blog: Il y a de nombreuses « distributions » qui en se contentent de changer l’esthétique et les applications installées par défaut. Je n’appelle pas cela de la dispersion, mais de la pollution pure et simple.

        Autre exemple au niveau des navigateurs web, si on prend le cas de Firefox, mis à part Tor Browser, je n’ai vu aucun fork qui se soit pas de la pollution.

    3. Peu importe ! Il s agit toujours d un weekend de trop qui aurait pu servir à améliorer les fonctionnalités essentielles !

      Ce qui manque à ces personnes c est savoir respecter un besoin client. En entreprise, si tu as deux fonctionnalités avec une super importante et l autre pas importante. Tu fais celle importante même si la pas importante prends que deux jours.

  4. Je suis d’accord pour le fait que beaucoup de navigateurs ne sont qu’une interface à des moteurs existants.

    En attendant, Surf, qui fait tourner du Webkit2GTK, ben il a pas vraiment d’équivalent et j’en suis bien content pour l’instant.

  6. Je ne sais pas si Solus aura un grand avenir à long terme, principalement dû à son choix de paquet obscur. Forcément, on finit toujours par tomber sur un logiciel qu’on souhaiterait avoir sur Solus, qui n’y est pas. Faut en faire la demande. Et ça prend du temps. Et encore, c’est pas certain que la demande soit acceptée. Puis, le bureau Budgie, faut aimer le minimalisme. Ça ne regorge pas de fonctionnalités, disons. Mais que ce soit avec Mate ou Gnome, le problème est le même côté logiciels. Bref, outre le grand talent technique du développeur, l’intérêt pour cette distribution demeure pour moi une énigme.

    1. Qu’est-ce que tu entends par choix obscur ?
      Je ne trouve rien d’anormal à devoir faire une demande pour de nouveaux paquets et que cela prenne un certain temps. En ce qui concerne l’acceptation des paquets, les règles sont claires : https://solus-project.com/articles/packaging/package-inclusion-policy/en/ C’est vrai que pour l’instant on freine un peu et qu’on refuse certaines applications quand il y en a 2 ou plus dans les dépôts qui font la même chose (*)

      Pour ma part, je constate que la logithèque s’accroît continuellement… Évidemment, il ne faut pas s’attendre à en avoir une aussi fournie que les grosses distributions qui sont installées depuis des années.

      (*) Des projets sont en cours afin de faciliter le travail de contributeurs, augmenter les capacités et pour automatiser certaines choses. Les dépôts tiers vont être remplacés par des paquets flatpak et donc pour le moment il n’y a plus d’ajout de nouvelles applications à ce niveau mais à terme tout cela va permettre d’améliorer la réactivité de ce côté.

      1. Choix obscur ?

        C’est simple. Le monde Linux tourne autour de deb ou rpm. Arch, avec le dépôt AUR, recompile ces paquets non disponibles. Solus devrait envisager une solution semblable, simple pour l’utilisateur. Un genre de Gdebi, mais qui recompilerait les paquets externes.

        Concernant les applications en Flatpak, le choix est plutôt limité jusqu’à présent. http://flatpak.org/apps.html Ce n’est clairement pas une solution pour suppléer au manque.

        Quoi qu’il en soit, leur choix d’utiliser eopkg (un maquillage de Pisi Linux) n’apporte rien de plus au final qu’un manque de disponibilités logicielles. Ça ressemble plus à une volonté de se démarquer, un trip d’égo, en faisant semblant de faire du neuf. Plusieurs des innovations sont pompées chez Intel Clear Linux, où travaille le développeur.

        Je reconnais toutefois son grand talent. L’installateur est très bon. L’accélération du démarrage est bienvenue. La fluidité de la distribution aussi. Cependant, il change souvent d’idées… Soit disant pour améliorer la distribution (ou être incapable de résoudre certains problèmes, alors on change, jusqu’aux prochains obstacles difficiles.) C’est ainsi que le projet est passé de Debian à PiSi, puis éventuellement à une solution dite maison. Budgie basé sur Gnome, puis bientôt sur QT, mais avec quand même des applications Gnome (GTK.)

        Pour la vision et la ligne droite vers un objectif clair, ça craint.

        1. Ca n’a rien à voir avec une volonté de se différencier ou un trip d’égo à moins que tu ne saches comment faire une distribution stateless qui utilise les paquets de distributions qui ne le sont pas ?
          Autre point important: la création des paquets eopkg (qui ve devenir sol) est également bien plus simple que la création de paquets au format debian ou redhat.

          Comme je l’ai dit, Flatpak (qui a été choisi par la communauté soit dit en passant) sera utilisé pour remplacer les applications tierces, et répond à ta critique initiale puisque le système permettra d’ajouter des applications sans devoir en faire la demande auprès de Solus, attendre et éventuellement voir sa demande refusée.
          Par ailleurs, tu ferais bien de lire la première phrase du lien que tu as posté :
          « This page lists some of the apps that are available as Flatpaks ».

          PS: Si la dispersion est un fléau, que penser des rageux qui crachent leur venin et qui foutent une ambiance de merde dans les communautés du libre? Il n’y a pas moyen de ne pas être d’accord et de critiquer sans pour autant dénigrer?

          1. « This page lists some of the apps that are available as Flatpaks »

            Quand tu en auras trouvé d’autres, merci de nous les indiquer, car il ne semble pas en exister encore.

            PS : Faut pas confondre venin, rage et opinion franche.

  7. On va dire que toutes ces distributions c’est comme les petits candidats, ils servent à rien, mais qu’est ce qu’on rigole grâce à eux.

    1. Tu connais mal python pour dire ça.
      Tu peux créer un « exécutable » python sans aucune dépense.
      Sache aussi que quasi toutes les distribs (debian/ubuntu, fedora/centos, arch, etc…) python est préinstallé de base.
      Dorénavant pour les fonctions de base d’une distribution, tout ce qui est bas niveau (pour des raisons de perfs) est codé en c/c++ et tout le reste est codé en python.
      C’est fini le temps ou les dèvs des distribs avaient une éternité devant eux pour tout bien fignoler en c/c++ pour gagner 5% de perf maintenant à chaque développement, ils choisissent entre c/c++ et python et c’est très souvent python qui gagne.
      Donc oui, un package manager en python, c’est exactement ce qu’il faut faire.
      Je ne dis pas ça par rapport à Solus, mais d’une façons générale.

        1. Ils l’écrivent eux même :
          « Python is really f*****g slow. Don’t use it for system-level components. »
          Mais l’arbitrage entre c/c++ et python n’est pas la.
          Pour la version python il y a 5 contributeurs et 11 forks.
          Pour la version c/c++ il y a 1 contributeur et 0 fork.
          En python tu peux fédérer quelques contributeurs et aller vite, en c/c++ le développement sera assez lent.
          Il n’y a pas de solution miracle.

  9. Lol Le development sous C++ est un peu lent…. Tu connais mal le C++ pour dire ça 😀
    Non svp, c’est surtout que les personnes qui le maîtrise ça courent pas les rues.

    Vu pour https://github.com/solus-project/sol écrit en C, j’ai très peur que ce sera encore un flop.

    Un gestionnaire de paquets parce que c’est un gestionnaire de paquets ne doit dépendre que du stricte minimum et si possible de rien du tout ( compilé en statique).

    1. « c’est surtout que les personnes qui le maîtrise ça courent pas les rues. »
      Ca revient exactement au même.
      Et tu sais quoi, le packet manager écrit en assembleur sera encore plus rapide mais « les personnes qui le maîtrise ça courent pas les rues. »
      Vaut mieux 10 bons contributeurs python ou un seul en c/c++ pour faire avancer un projet ?
      C’est marrant comment on revient toujours à cette guerre de religion des technos.
      Tant que le packet manager répond aux besoins et que le projet avance, qu’il soit en python, c/c++, javascript, go ou je ne sais quelle autre techno, peu importe.

Les commentaires sont fermés.