Développer des applications pour Linux

 (makealinux.app)
1 points par GN⁺ 2023-12-11 | 1 commentaires | Partager sur WhatsApp
  • Les environnements Linux sur desktop et mobile ont besoin de nouveaux logiciels, mais les boutiques d’apps et dépôts manquent d’applications ; le message est donc de se concentrer sur le développement d’apps plutôt que sur de nouvelles distributions
  • Même une app née d’un besoin personnel peut, si elle est développée au grand jour, devenir une ressource d’apprentissage et une communauté, et ainsi contribuer à l’extension de l’écosystème Linux
  • La diversité de centaines de distributions peut sembler lourde, mais des systèmes de packaging et de distribution bien documentés permettent de livrer des apps aux utilisateurs de nombreux environnements
  • GNOME, KDE Frameworks, elementary OS, Electron et Ubuntu Touch offrent des parcours de développement différents avec Gtk, Qt, Vala, JavaScript·HTML·CSS et QML
  • Il existe des moyens de distribution comme AppCenter, AppImage, Flatpak, Open Build Service et Snapcraft, avec aussi des possibilités de monétisation via des apps payantes, des services et des app stores reposant sur le soutien des utilisateurs

Pourquoi Linux a besoin de plus d’applications

  • Les utilisateurs de Linux sur desktop et mobile ont une demande pour de nouveaux logiciels
  • Les boutiques d’apps et dépôts Linux manquent d’applications par rapport aux plateformes propriétaires
  • Les passionnés de technologie sont invités à consacrer leur passion et leur créativité à de nouvelles applications pour les utilisateurs de Linux plutôt qu’à créer encore plus de distributions Linux
  • Le message central est : « Arrêtez de créer des distributions Linux, créez des applications »

L’effet du développement d’applications sur l’écosystème

  • Si vous avez une idée d’application répondant à un besoin personnel, d’autres utilisateurs peuvent avoir le même besoin
  • En développant publiquement une application, des développeurs plus débutants peuvent aussi apprendre et se lancer, ce qui aide la prochaine génération de développement d’apps Linux
  • Le développement d’applications est un travail créatif, et le sentiment d’accomplissement une fois le projet terminé peut aussi être une récompense
  • Le développement d’apps aide à former une communauté, et la communauté Linux veut souvent aider les développeurs à réussir
  • Les compétences en développement logiciel sont recherchées, et il existe aussi de nombreuses ressources d’apprentissage gratuites
  • L’idée selon laquelle les utilisateurs de Linux ne soutiennent pas financièrement les développeurs est une idée reçue ; des applications et services payants populaires peuvent créer de nouvelles sources de revenus

Cibler la diversité des distributions Linux

  • Contrairement à d’autres plateformes, Linux vise un ensemble très diversifié, avec des centaines de distributions
  • Une fois publiée, une application peut généralement fonctionner dans de nombreux environnements
  • Il existe des systèmes de packaging et de distribution bien documentés qui permettent aux développeurs de livrer leurs apps aux utilisateurs
  • Chaque framework de développement et chaque distribution Linux ont un chemin recommandé pour distribuer les applications aux utilisateurs
  • Quand l’app est prête à être partagée, on peut consulter dans la documentation de développement les guides de packaging recommandés

Des voies pour se lancer dans le développement

  • GNOME

    • Le projet GNOME développe le desktop GNOME Shell et prend en charge le développement basé sur Gjs et Gtk
    • Avec Gtk, on peut utiliser des langages populaires comme Python, C, C++, Rust et JavaScript
    • GNOME Developer Center

  • KDE Frameworks

    • KDE fournit le desktop Plasma ainsi que des outils et frameworks pour créer des applications
    • KDE Frameworks est utilisé depuis longtemps pour développer une grande variété d’applications desktop
    • Il s’appuie principalement sur la boîte à outils Qt et le langage C++
    • KDE Frameworks Getting Started

  • elementary OS

    • elementary OS se présente comme un système d’exploitation rapide, ouvert et respectueux de la vie privée, pensé comme alternative à Windows et macOS
    • Ses développeurs construisent un desktop et un écosystème pour le développement d’applications
    • Le guide développeur recommande Vala et Gtk
    • elementary OS Developer Guide

  • Electron

    • Electron permet de créer des applications desktop multiplateformes avec JavaScript, HTML et CSS
    • Les développeurs peuvent s’appuyer sur la vaste bibliothèque de modules node pour créer des apps fondées sur les technologies web
    • Electron Documentation

  • Ubuntu Touch

    • Ubuntu Touch est un système d’exploitation open source conçu pour fonctionner sur une grande variété d’appareils, dont téléphones, tablettes et PC
    • Les applications natives Ubuntu Touch se créent en QML ou en HTML, avec une logique définie en JavaScript, C++, Python, Rust ou Go
    • Ubuntu Touch Documentation

Ce qu’en pensent les développeurs de l’écosystème Linux

  • Neil McGovern, de la GNOME Foundation, estime qu’un écosystème d’applications florissant est nécessaire pour amener Linux au grand public, et que tout le monde devrait pouvoir développer pour Linux afin de se rapprocher de l’objectif d’un desktop ouvert
  • Aleix Pol, de KDE e.V., explique que, pour faire de Linux le système d’exploitation de son choix, il faut d’excellentes applications, et que les outils de développement permettent de créer ce que l’on imagine
  • Daniel Foré, fondateur d’elementary, considère qu’il est possible non seulement de créer d’excellentes applications pour Linux desktop, mais aussi de concevoir des API de plateforme et d’influencer l’orientation du desktop
  • Jan Sprinz, membre du conseil d’administration de l’UBports Foundation, explique que le développement d’apps Linux est totalement différent des écosystèmes fermés : même en concurrence sur le plan technique, les acteurs coopèrent pour une vision plus large

Comment partager et distribuer les applications

  • AppCenter

    • Une boutique d’apps ouverte de type pay-what-you-want et un service de build pour les développeurs indépendants
    • AppCenter Dashboard s’intègre à GitHub et prend en charge les releases ainsi que le suivi des issues
    • AppCenter Dashboard

  • AppImage

    • Les applications desktop Linux peuvent être distribuées au format AppImage afin de toucher les utilisateurs des distributions Linux les plus courantes
    • Le principe mis en avant est de packager une fois pour exécuter partout
    • AppImage Packaging Guide

  • Flatpak

    • Un framework de distribution pour les applications desktop Linux
    • Il a été créé par des développeurs actifs de longue date sur Linux desktop et fonctionne comme un projet open source indépendant
    • Flatpak Documentation

  • Open Build Service

    • openSUSE Build Service est l’instance publique d’Open Build Service
    • Il est utilisé, en plus du développement de la distribution openSUSE, pour fournir à partir d’une même source des paquets pour Fedora, Debian, Ubuntu, SUSE Linux Enterprise et d’autres distributions
    • openSUSE Build Service Help

  • Snapcraft

    • Snapcraft est un outil en ligne de commande pour créer des snaps
    • Les snaps sont présentés comme des paquets d’applications pour le desktop, le cloud et l’IoT, faciles à installer, sûrs, multiplateformes et sans dépendances
    • Snapcraft Documentation

À lire aussi

1 commentaires

 
GN⁺ 2023-12-11
Avis sur Hacker News

  • Je pense que le postulat est erroné, car il n’existe toujours pas sur Linux d’ensemble de frameworks fondamentaux à ABI stable
    Les plateformes concurrentes disposent de bien plus de frameworks de base comme CoreImage, CoreAudio, CodeML, SceneKit et AppKit, et ils cassent moins souvent
    Snap ou Flatpak sur Linux sont intéressants aussi, mais cela ressemble davantage à un contournement par l’infrastructure et la gestion de paquets, au lieu de résoudre le problème au niveau des frameworks et du langage de programmation que les applications demandent

    • La communauté des passionnés de Linux a tendance à s’opposer activement à cette orientation, parce qu’elle veut rendre tout modulaire et l’assembler selon les besoins de chaque application
      Il existe bien sur Linux des ensembles standards de facto, mais comme ils changent et sont parfois abandonnés, ils sont moins stables. Cela dit, c’est mieux qu’il n’y paraît, et Snaps peut atténuer une partie du problème
      En revanche, si les gens choisissent une distribution dépourvue de tels standards, on perd potentiellement la moitié des utilisateurs dès qu’on ne prend pas en charge toutes sortes de configurations exotiques
    • J’ai lu quelque part qu’aujourd’hui, la cible la plus stable sur Linux est Win32 via Wine ou Proton
    • Au cœur de tout cela, il y avait les frameworks GNOME ou KDE et les standards FreeDesktop, du moins c’était le plan il y a 20 ans
      Mais comme le dit l’article, la plupart continuent surtout à fabriquer des distributions, et il devient naturellement difficile de voir émerger une pile unique capable de suivre l’innombrable quantité de distributions atypiques
      Au final, Google a pris le noyau Linux et y a superposé deux ensembles de frameworks centraux basés sur Java et JavaScript, et auprès du grand public, ce sont ces distributions Linux qui ont gagné
    • À mon avis, la responsabilité principale revient aux développeurs de glibc. L’abus des noms de version et des choses comme l’ajout récent de nouveaux types de relocalisation ELF rendent la distribution de binaires de jeux sur plusieurs distributions extrêmement pénible
      En général, les développeurs de jeux compilent sur une grande distribution récente puis publient sur Steam, et si cette distribution embarque glibc 2.36, le binaire se retrouve souvent avec des noms de version exigeant glibc 2.36 ou plus
      Au final, il faut utiliser la directive symver de binutils gas pour forcer des noms de version compatibles avec une glibc suffisamment ancienne. Personnellement, je considère 5 ans, voire 7 à 8 ans, comme un seuil raisonnable : https://sourceware.org/glibc/wiki/Glibc%20Timeline
      Le développeur de jeux moyen ignore presque totalement ce problème, et même s’il le connaît, il n’acceptera probablement pas une telle souffrance pour 1 % du marché. Pour éviter ces problèmes d’ABI, il faut aussi lier statiquement libgcc et, en C++, probablement libstdc++
      Cela dit, le moteur Godot fournit des conteneurs de build qui font attention à ce genre de choses, et Unity semble aussi assez propre sur ce point. Je ne sais pas trop pour UT5.x
      À l’inverse, il existe des moteurs mal préparés, comme dans les jeux basés sur Electron. Ils peuvent ne pas se lancer s’il n’existe pas, pour la distribution visée, de version appropriée de GTK+ pour Enlightenment, Qt, X11 pur ou Wayland
      Emballer correctement tout le moteur Google Blink puis le distribuer en binaire pour un large éventail de distributions ELF/Linux n’a rien de simple non plus
      ELF/Linux est globalement hostile à la distribution de binaires propriétaires à cause des ruptures d’ABI, en particulier dans les SDK et les bibliothèques cœur
      Si c’est déjà aussi difficile pour des binaires de jeux, ce sera encore plus dur pour des applications. On imagine bien les développeurs finir par dire : « peu importe, installez simplement Microsoft SUSE GNU/Linux et utilisez ça, le reste n’est pas pris en charge »
    • Si Linux disposait d’une palette de frameworks comparable à celle de macOS, j’aurais depuis longtemps ciblé Linux pour mes projets personnels
      Le fait d’avoir autant d’outils qu’on peut utiliser immédiatement, sans presque se soucier de la durée du support, du meilleur fork, ou de la compatibilité avec d’autres bibliothèques tierces, est remarquable. Cela réduit énormément les frictions et permet de simplement créer
      Les écosystèmes KDE Qt et GNOME/GTK sont ce qui s’en rapproche le plus, mais on n’en est pas encore là

  • Il est possible qu’on ne connaisse pas le schéma qui détermine quand ajouter dev et version dans les noms de paquets, ni ce que signifient les 1 ou 0 arbitraires à la fin, mais la première distribution Linux à adopter des règles de nommage de paquets cohérentes gagnera probablement les cœurs
    libgnutls-dev
    libgtk-3-0
    libwayland-server0
    libxcb1
    libx11-6
    libffi-dev
    libncurses5-dev

    • -dev contient les en-têtes, donc c’est assez simple
      Les chiffres indiquent la version quand plusieurs versions peuvent être installées en même temps. Cela dit, il peut y avoir des exceptions comme xcb1, où le chiffre fait partie du nom de la bibliothèque
      Par exemple, à un moment donné, on pouvait sans doute installer libgtk-3-0 et libgtk-2-$something en même temps. Plus tard, même après la suppression de libgtk-2, le nom a probablement été conservé pour que les références à libgtk-3-0 dans les anciens tutoriels ne cassent pas
      Pour le 0 final de libwayland-server0, je ne sais pas trop non plus. Je vois bien dans /var/lib la même bibliothèque avec plusieurs suffixes en .$number, mais je n’ai jamais creusé ce que cela résout exactement
    • Séparer les binaires et les sources est une convention Debian. Si l’on veut seulement utiliser une bibliothèque, le paquet sans -dev suffit ; si l’on veut développer avec cette bibliothèque, il faut aussi -dev, qui installe les en-têtes
      Le 1 ou le 0 à la fin n’a rien de spécial : cela fait simplement partie du nom ou de la version du paquet
    • Dans Arch et ses distributions dérivées, on ne voit généralement pas ce genre de chose
      En revanche, -dev désigne ce qui n’est nécessaire que lorsqu’on développe pour cette bibliothèque
      Les chiffres sont des numéros de version majeure, c’est-à-dire des numéros de compatibilité. Cela permet d’installer facilement côte à côte plusieurs versions majeures dont dépendent différents paquets, sans conflit
    • Si l’on compile un programme, il suffit d’installer le paquet -dev. En général, on n’a pas à se soucier directement des paquets -dev numérotés ; si c’est nécessaire, le paquet sans numéro est censé faire le relais
      Pendant la compilation, on enregistre quel suffixe numérique — c’est-à-dire la version d’ABI — a été utilisé. Il doit correspondre au suffixe .so.N, mais on ne le recherche pas directement sous cette forme
      Grâce à ce mécanisme, on peut installer plusieurs copies incompatibles d’une même bibliothèque, et la bonne sera utilisée selon le cas. Les distributions nettoient généralement les anciennes à chaque grosse release
      À l’installation, les dépendances enregistrées à la compilation devraient être utilisées automatiquement
    • Il y a GoboLinux, qui de mon point de vue résout tout cela sans être aussi complexe que Nix. Mais personne n’y a prêté attention

  • C’est l’un des plus gros problèmes qui plombent l’ensemble de la plateforme Linux. On le présente souvent comme un avantage, mais je ne le vois pas ainsi
    Les développeurs mettent en avant le grand nombre de choix possibles comme une force de Linux, mais pour beaucoup d’utilisateurs, cela devient un paradoxe du choix qui les pousse à revenir à leur plateforme d’origine
    Sur macOS et Windows, il y a moins d’options, mais les options disponibles sont bien plus abouties et moins fragmentées
    Par exemple, de combien de gestionnaires de fenêtres en mosaïque a-t-on vraiment besoin ? Ne pourrait-on pas choisir le meilleur et construire un meilleur dock et de meilleures applets autour ? Et des applications et lanceurs intégrés au paradigme des gestionnaires de fenêtres en mosaïque ?
    À la place, on se retrouve souvent avec 10 gestionnaires de fenêtres en mosaïque et des programmes de contournement à moitié finis empilés par-dessus

    • Les gens ne choisissent pas en analysant exhaustivement toutes les options. Ils regardent un petit nombre de candidats, puis en prennent un selon sa popularité ou son accessibilité
      Un écosystème réussi fait en sorte qu’en choisissant une option bien visible, on obtienne malgré tout un résultat suffisamment correct
      La multiplication des distributions Linux n’est le plus souvent qu’une affaire de petites différences qui ne réduisent guère l’adéquation réelle, et seuls de très rares utilisateurs qui n’avaient déjà aucun mal à choisir une distribution y voient un problème
      En revanche, avec Wayland par exemple, la tuyauterie interne et le matériel deviennent soudain importants, et il faut comprendre un minimum l’architecture interne pour choisir une combinaison utilisable : là, c’est un vrai problème
      Comparer Mac ou Windows à Linux n’a d’ailleurs pas beaucoup de sens. Pour 95 % des consommateurs, le système d’exploitation est une caractéristique fixe de l’ordinateur, ou une fonctionnalité, pas un produit distinct
      Ils peuvent acheter un ordinateur livré avec tel système si l’ensemble leur convient, mais ils n’essaieront pas de l’installer séparément sur leur machine Windows ou Mac
      Les personnes ayant assez de connaissances techniques pour être satisfaites ne seront probablement pas très déstabilisées si trois dérivées d’Ubuntu et deux dérivées d’Arch supplémentaires apparaissent
    • Créer un gestionnaire de fenêtres en mosaïque, c’est amusant. Produire du logiciel de manière collaborative n’est pas seulement un moyen d’obtenir un résultat : c’est aussi une fin en soi
      Devenir développeur open source, c’est pouvoir décider soi-même de ses objectifs et de ses moyens, alors qu’en développement logiciel commercial, cette liberté n’existe souvent pas
      Cela crée des aspects rugueux, mais au final on finit par aimer ça grâce à l’effet IKEA
    • C’est aux distributions de résoudre ce problème. Les gens qui ne veulent pas d’un grand nombre de choix peuvent utiliser une distribution qui fait beaucoup de choix à leur place ; il n’est pas nécessaire d’exiger la suppression des options à l’échelle de tout l’écosystème
      Si tout le monde utilisait le même logiciel, on se retrouverait avec un écosystème de monoculture plus vulnérable aux attaques. Si Windows a été autant ciblé par les virus, c’est aussi parce que la cible était vaste et uniforme
      Une fois qu’on perçait la machine Windows d’un utilisateur lambda, on pouvait souvent percer les autres de la même manière. Avec Linux, c’est bien plus difficile
      En plus, c’est du logiciel libre. Sauf à payer quelqu’un pour le faire, il s’agit le plus souvent de bénévolat, et nous n’avons pas à dire aux bénévoles où ils doivent consacrer leur temps
      Et s’il existe autant de groupes mais que personne ne veut les rejoindre, il faut aussi examiner la structure sociale dominante. Supprimer, pour commencer, les codes de conduite qui permettent de sanctionner des comportements en dehors du projet pourrait être un point de départ
    • Je pense qu’il y a encore plus de lanceurs et de docks que de gestionnaires de fenêtres en mosaïque
      Et je ne vois pas très bien ce qu’il faudrait encore améliorer. Des outils comme Ulauncher ou Albert sont bien plus puissants que ce qui est possible sur d’autres plateformes, et je ne vois pas non plus comment rendre l’UI meilleure
    • Il suffit qu’il y ait autant de gestionnaires de fenêtres en mosaïque que les gens ont envie d’en créer

  • C’est une bonne chose qu’il y ait davantage de logiciels. Mais avant de repartir de zéro, pourquoi ne pas contribuer à quelque chose qui existe déjà, ou choisir un projet abandonné, ou qui a besoin d’être remis en état pour se compiler et s’exécuter avec des compilateurs et du matériel récents
    Je me demande aussi s’il existe quelque part une base de données de projets en sommeil ou morts qui vaudraient la peine d’être relancés

    • Il se peut qu’une solution existante ne soit pas conçue de la manière que je vise
      Un autre projet peut aussi être dirigé par quelqu’un avec qui il est difficile de travailler, ou par une communauté qui n’accepte ni propositions ni patchs
      Les procédures sociales et les blocages peuvent faire perdre la motivation de contribuer. Tout le monde ne peut pas être un coéquipier optimiste et sans aspérités
      Pour ma part, je préfère repartir de zéro. Cela me permet de contrôler toutes les variables, d’éviter d’avoir à toucher à une infrastructure sociale et technique existante, de ne pas devoir convaincre quelqu’un que mes idées sont bonnes, et parce que je n’ai pas envie de passer plus de temps en débats et discussions qu’à écrire du code
      L’expérience du développement en solo me convient mieux. On n’est pas prisonnier de la politique et des procédures sociales, et être un joueur d’équipe ne m’a apporté que de la souffrance
    • Dans la plupart des domaines, il y a trop de tentatives médiocres ; si cet effort était concentré sur quelques projets majeurs, on pourrait obtenir quelques excellentes applications
      La collaboration peut sembler lourde et difficile, mais au bout du compte il s’agit de produire des résultats, et c’est un meilleur usage du temps que de l’investir dans des projets qui seront abandonnés
    • Je me demande s’il existe, parmi les principaux dépôts de paquets Linux, un endroit qui compile des statistiques permettant de repérer les applications largement utilisées mais non maintenues ou inachevées

  • Beaucoup se plaignent du manque d’outils pour créer des applications compatibles avec plusieurs systèmes d’exploitation, mais je ne suis pas d’accord. Il existe des solutions autres qu’Electron
    Telegram utilise Qt pour distribuer sur les trois systèmes d’exploitation des applications natives performantes
    Flutter compile en code natif pour les trois systèmes d’exploitation ainsi que pour le mobile
    Kirigami est un framework QtQuick qui permet de créer des applications exécutables à la fois sur mobile et sur desktop
    Il suffit simplement de créer l’application. Il n’y a aucune raison d’en faire un prétexte pour blâmer Linux

    • Flutter se comporte légèrement différemment selon les plateformes, ce qui donne sur chacune une expérience subtilement insatisfaisante. Quant à Kirigami ou Qt Quick, il est difficile de les considérer comme des options réellement viables
      Il n’existe pratiquement ni communauté ni projets sérieux sur Windows, macOS et mobile. Ce n’est pas pour rabaisser KDE, c’est simplement la réalité
      La licence de Qt Quick n’est pas simple non plus sur iOS, et si l’on vise le commercial, cela devient très coûteux
      À l’inverse, de grandes entreprises investissent dans Electron et en font un outil de niveau production très abouti, avec une immense communauté et un écosystème de bibliothèques massif, sans compter que ce n’est pas un langage méconnu comme Dart
      Telegram fait réellement un effort supplémentaire. Le client est excellent
    • L’application Telegram basée sur Qt fonctionne aussi bien sur macOS, mais la plupart des utilisateurs Apple choisissent un client Swift/Cocoa pour macOS et iOS[0]
      [0]: https://github.com/overtake/TelegramSwift

  • Le problème, c’est que les logiciels OSS n’essaient même généralement pas vraiment de rivaliser sur le marché.
    Les personnes qui utilisent des logiciels OSS considèrent comme normal qu’il y ait un déficit d’UX, et dans les faits c’est souvent le cas.
    Les logiciels propriétaires classiques s’adaptent pour offrir une bonne expérience utilisateur finale, car ils risquent que les utilisateurs ne paient pas, mais l’OSS n’est généralement pas exposé à ce risque. L’open source devrait lui aussi être exposé au risque venant des utilisateurs finaux.
    J’ai essayé de changer cela avec Notes[1], mais j’ai compris qu’il est difficile d’en vivre avec la seule publicité. J’ai aussi tenté d’ajouter des fonctionnalités premium payantes, comme un Kanban, mais l’app étant entièrement FOSS, n’importe qui peut facilement la compiler à partir des sources.
    Pour la prochaine app[2], je compte partir sur du code source fermé avant le lancement. Je ne peux pas accepter le risque que mes efforts ne soient pas récompensés.
    Si je peux me faire payer, je pourrai investir davantage dans des apps centrées sur l’UX sur Linux, ce qui bénéficiera aussi à la communauté Linux. Je pourrai peut-être en publier une partie en open source, et peut-être, dans un avenir lointain, publier le tout.
    [1] https://github.com/nuttyartist/notes
    [2] https://www.get-plume.com

    • Il y a un fort recoupement entre les utilisateurs de Linux et les personnes qui tiennent à leur liberté. Pour beaucoup, une app de prise de notes non open source n’est pas une option dès le départ, à cause du vendor lock-in et des questions de vie privée.
      Donc, si le programme n’est pas open source, il est probable qu’on perde davantage qu’en le rendant open source et en acceptant le risque qu’une partie des gens ne paie pas.
      Je pense qu’il y aura bien plus de gens prêts à payer pour utiliser de l’open source que de gens voulant utiliser du logiciel propriétaire.
      Open source ne veut pas forcément dire qu’il faut distribuer le code à tout le monde ; si c’est payant, on pourrait ne donner le code source qu’aux utilisateurs payants. En revanche, ils auraient alors le droit de le modifier et de le redistribuer.
      Si l’open source ne vous intéresse pas, vous pouvez utiliser Notion ou Evernote. Si vous cherchez une app de prise de notes open source moderne, je recommande Logseq.
    • J’ai l’impression que c’est la bonne décision. Gagner de quoi vivre avec l’open source est extrêmement difficile, et le nombre de personnes qui en vivent est inférieur de plusieurs ordres de grandeur à celui des personnes qui vivent du logiciel commercial.
    • Je comprends la frustration, mais il existe aussi des contre-exemples. Ce n’est pas pour rabaisser qui que ce soit.
      D’abord, Notes ressemble pas mal à Standard Notes. Si Notes a été créé en utilisant de l’OSS sous copyleft, j’ai du mal à voir comment on peut se plaindre, sauf à verser des royalties pour le travail des autres programmeurs intégré dedans.
      Ensuite, je suis probablement un utilisateur atypique. J’utilise Linux depuis plus de 20 ans, mais je suis incapable d’écrire correctement ne serait-ce qu’un script Bash ou une one-liner Perl.
      Pourtant, comme je ne sais pas coder et que j’apprécie le travail des autres ainsi que la liberté qu’il apporte, j’ai dépensé bien plus d’argent en logiciels que ce que des particuliers dépensent habituellement sur d’autres plateformes.
      Je soutiens entre autres Kaisen et Debian, les utilitaires de base de la FSF et Emacs, KDE, Firefox de Mozilla, Betterbird, Syncthing, LaGrange, Joplin, ClipTo, ainsi que des services comme SoulSeek et envs.net.
      Pour certains, je paie chaque année ; pour d’autres, chaque mois ; pour d’autres encore, une seule fois.
      Quand Standard Notes est sorti, j’ai aussi payé un abonnement de 7 ans, mais j’ai arrêté après environ deux mois, faute d’en être satisfait. Il y a aussi des outils que j’utilise beaucoup, comme Alacritty, sans avoir trouvé de moyen de faire un don, et j’essaie de limiter ce genre de cas au minimum.
    • Personnellement, je trouve que KDE est très loin devant macOS et Windows.
      En réalité, macOS me semble avoir l’un des pires gestionnaires de fenêtres parmi les plateformes populaires. C’est joli et facile à utiliser, mais dès qu’on veut faire quelque chose au-delà des bases, il faut des formules magiques impossibles à découvrir naturellement.
      Bien sûr, chacun ses goûts.
    • J’ai quelques réflexions. Même en suivant assez bien ce secteur, je n’avais jamais entendu parler de cette app, et la concurrence est extrêmement rude.
      J’ai cliqué pour voir le tarif premium ; à l’année cela me paraît raisonnable, mais comme seule l’option d’abonnement mensuel était affichée, j’ai trouvé cela dissuasif.
      Pour ce type d’app, je serais plus susceptible de faire un don que de payer une version premium. Ce modèle a bien fonctionné pour Obsidian.
      Je ne pense pas que l’accès anticipé aux fonctionnalités ait beaucoup de valeur, mais beaucoup de gens paient pour soutenir le travail.
      Je pense aussi qu’un grand écosystème open source autour d’un produit cœur fermé donne aux gens une raison de payer.

  • J’aurais aimé qu’il y ait quelques exemples dans l’article.
    Je crée une distribution, et en réalité je ne vois pas bien qui devrait plutôt créer des applications. En forçant un peu, peut-être LinuxCNC ? Mais comme il y a des exigences spécifiques côté noyau, une distribution personnalisée est peut-être plus adaptée dans ce cas.

    • Un environnement de bureau est en pratique une application qu’on peut installer facilement en un ou deux clics ou avec une commande.
      J’ai du mal à comprendre les distributions dérivées de distributions dérivées qui ne sont diffusées que pour embarquer un environnement de bureau différent.

  • Plutôt que « Arrêtez de créer des distributions Linux, créez des applications », je pense qu’il vaudrait mieux arrêter d’écouter les gens qui disent aux autres ce qu’ils doivent ou ne doivent pas faire.

    • Ce ton m’a aussi agacé.
      Cela dit, le message et les informations eux-mêmes sont bons.
      Personnellement, j’aurais plutôt dit quelque chose comme : « Les utilisateurs de Linux ne veulent pas plus de distributions. Ils veulent des logiciels. » En tout cas, moi oui.
    • Il faut aussi arrêter d’écouter les gens qui disent d’arrêter d’écouter les gens qui disent aux autres ce qu’ils doivent ou ne doivent pas faire. Tout n’est pas relatif : il y a de bons choix et de mauvais choix.

  • Je suis récemment passé de Mac à Linux, afin d’utiliser un matériel d’occasion performant comme machine du quotidien
    J’avais déjà installé Linux sur plusieurs machines auparavant, mais cette fois-ci ce n’est pas juste un hobby
    Ubuntu prend bien en charge mon matériel et mes périphériques, mais l’app store semble inachevé et un peu plaqué de force. Malgré cela, presque tout fonctionne comme prévu
    J’aimerais aussi regarder Mint, Debian et Arch, mais je reste prudent, car beaucoup de logiciels semblent conçus en pensant à Ubuntu

    • Linux Mint est basé sur Ubuntu, donc on peut utiliser les paquets Ubuntu sans problème. On peut pratiquement le considérer comme un meilleur Ubuntu
      Il existe aussi une version de Mint basée sur Debian, mais c’est surtout une solution de secours pour éviter une dépendance critique à Ubuntu
      De nos jours, utiliser une distribution atypique ne pose plus vraiment de problème. Si le gestionnaire de paquets par défaut ne fournit pas l’application voulue, on peut utiliser AppImage, Flatpak ou Snap
    • Parmi les logiciels conçus pour Ubuntu, il n’y en a pratiquement aucun qui ne tournerait pas sur Arch ou sur la plupart des distributions récentes
      Quand j’utilisais Arch, il fallait surtout s’habituer aux hypothèses que les gens font en prenant Ubuntu comme référence, mais la plupart du temps il suffisait de corriger des fichiers de configuration ou de définir des variables d’environnement
      Ce sont des compétences utiles et transférables ailleurs
    • Fedora vaut aussi vraiment la peine d’être essayé au moins une fois
      Je me dis que j’aurais aimé l’utiliser plus tôt

  • Je ne vois pas pourquoi quelqu’un ferait ça. C’est plus difficile, et les utilisateurs de Linux ne paient pas pour ce qui ne vaut pas le prix demandé

    • Parce qu’il est bénéfique pour tout le monde qu’il y ait davantage de logiciels gratuits de qualité