Je comprends ton point de vue. Je propose effectivement une série de concepts qui ne sont pas particulièrement originaux, puisque la plupart des distributions les revendiquent également. Il y a toutefois une nuance à apporter : dans SlyOS, chacun de ces concepts correspond à des choix concrets et peut être justifié par des éléments précis.
Moderne → SlyOS propose niri, un gestionnaire de fenêtres Wayland relativement récent, qui a déjà fait ses preuves et qui bénéficie d’un développement actif.
Léger → SlyOS se compose du nombre de paquets le plus limité possible. La version minimale contient moins de 700 paquets, tandis que la version complète en contient moins de 850. Cela réduit le nombre de composants susceptibles de poser problème et permet de conserver une consommation de ressources limitée. Les ISO de la version 0.2, « Invativ », sont également nettement plus légères que celles de nombreuses distributions Linux destinées à l’architecture x86_64, sans pour autant supprimer les fonctionnalités essentielles.
Simple à utiliser → SlyOS propose un programme d’accueil accessible depuis l’environnement live ou après l’installation. Il permet notamment de découvrir les principaux raccourcis et les outils disponibles. Le système peut également être utilisé sans passer par la ligne de commande grâce à Pamac, le gestionnaire de logiciels issu de Manjaro. Ce dernier est toutefois intégré à un système globalement beaucoup plus lourd que SlyOS.
Personnalisable → SlyOS s’appuie sur différents outils de personnalisation pour Wayland, comme Ironbar, Wofi, Hyprlock ou Vibepanel. Ils permettent d’obtenir un environnement de bureau suffisamment complet tout en laissant une grande liberté de modification. Il est possible de désinstaller ces outils et de les remplacer par d’autres alternatives. Le choix de niri facilite également cette personnalisation, puisque le gestionnaire de fenêtres est conçu pour être configuré en profondeur.
Performant → SlyOS utilise le noyau linux-cachyos, dans sa variante LTS, afin de bénéficier d’un bon compromis entre performances et stabilité. Le système consomme également peu de mémoire vive au démarrage grâce à l’utilisation d’OpenRC, de niri et d’un nombre limité de programmes. L’objectif est de proposer un bureau suffisamment complet pour un usage quotidien, sans multiplier les services exécutés en arrière-plan.
KISS → SlyOS utilise OpenRC, un gestionnaire de services qui suit une approche plus modulaire et plus proche du principe KISS que systemd. Ce dernier est régulièrement critiqué pour l’étendue de ses fonctionnalités, son poids et la complexité qu’il peut introduire dans le système. Ce choix ne signifie pas que systemd est inutilisable, mais simplement qu’OpenRC correspond davantage à la philosophie que je souhaite suivre avec SlyOS.
Intuitif → SlyOS présente les principaux raccourcis dès l’ouverture de l’environnement live ou après l’installation. Son bureau minimal, ainsi que l’accès aux paramètres et aux logiciels sans obligation d’utiliser la ligne de commande, doivent permettre à un utilisateur débutant de prendre rapidement le système en main. C’est toutefois un aspect qui se juge surtout à l’utilisation, et pas uniquement à partir de la liste des logiciels installés.
Je comprends également que l’explication est plus facile à suivre dans un commentaire que sur un site web. Cependant, j’ai aussi d’autres contraintes et je ne peux pas rédiger un long texte explicatif pour chaque échange, d’autant plus que je prévois de publier une dépêche consacrée au projet. Le meilleur moyen de se faire une opinion reste donc de tester SlyOS, par exemple dans une machine virtuelle.
La philosophie d’une distribution se manifeste d’abord par les choix logiciels qui la composent. C’est pour cette raison que je présente ces différents composants : ils permettent de comprendre concrètement la direction prise par SlyOS.
Concernant la remarque sur les concepts « flous » ou consensuels, je ne suis pas opposé à l’idée de présenter plus directement ce qui distingue SlyOS. Chaque concept est cependant associé à des choix précis, qui sont déjà expliqués dans les principes du projet et illustrés dans la galerie. Le caractère intuitif est plus difficile à résumer par la présence d’un logiciel particulier, puisqu’il dépend surtout de l’expérience d’utilisation.
Pour le point concernant le logiciel libre qui devient payant, ma position concerne principalement le modèle économique de Qt. Je ne reproche pas à un projet libre de chercher à se financer. Ce qui me dérange davantage, c’est que Qt repose notamment sur les revenus provenant de logiciels propriétaires et de licences commerciales. Je préfère donc soutenir des projets qui privilégient d’autres modèles, comme les dons, à l’image de ce qui existe autour de GTK.
Ma position peut paraître controversée, notamment parce que l’écosystème Linux dépend lui aussi largement de grandes entreprises, y compris Microsoft. Je ne prétends donc pas pouvoir éviter toute dépendance de ce type, mais j’essaie, autant que possible, de privilégier des logiciels et des projets capables de subsister sans être directement financés par le logiciel propriétaire.
Enfin, concernant la vie privée, remplacer systemd par OpenRC ne constitue évidemment pas, à lui seul, une garantie de meilleure confidentialité. Ce choix répond surtout à trois objectifs : éviter de renforcer la position dominante de systemd, utiliser un composant plus léger et rester plus proche du principe KISS.
Je considère néanmoins qu’OpenRC offre une approche plus prévisible et plus limitée dans son périmètre. Les inquiétudes récentes autour de l’ajout d’un champ birthDate dans les données utilisateur de systemd illustrent la raison pour laquelle je préfère limiter les composants centraux aux fonctions dont le système a réellement besoin. Le problème n’est pas uniquement l’existence de ce champ, qui peut être présenté comme optionnel, mais aussi le fait que systemd puisse devenir un point central pour intégrer ce type de mécanisme à l’avenir.
Je ne prétends pas qu’OpenRC garantit une meilleure confidentialité sur tous les plans. Je dis simplement que son périmètre plus restreint et son fonctionnement plus modulaire correspondent davantage au niveau de contrôle que je souhaite conserver dans SlyOS.
[^] # Re: Philosophie ?
Posté par Minaucro (site web personnel) . En réponse au journal SlyOS, un système basé sur Arch linux avec OpenRC, ReGreet et le gestionnaire de fenêtres niri. Évalué à 8 (+8/-0).
Je comprends ton point de vue. Je propose effectivement une série de concepts qui ne sont pas particulièrement originaux, puisque la plupart des distributions les revendiquent également. Il y a toutefois une nuance à apporter : dans SlyOS, chacun de ces concepts correspond à des choix concrets et peut être justifié par des éléments précis.
Moderne → SlyOS propose niri, un gestionnaire de fenêtres Wayland relativement récent, qui a déjà fait ses preuves et qui bénéficie d’un développement actif.
Léger → SlyOS se compose du nombre de paquets le plus limité possible. La version minimale contient moins de 700 paquets, tandis que la version complète en contient moins de 850. Cela réduit le nombre de composants susceptibles de poser problème et permet de conserver une consommation de ressources limitée. Les ISO de la version 0.2, « Invativ », sont également nettement plus légères que celles de nombreuses distributions Linux destinées à l’architecture x86_64, sans pour autant supprimer les fonctionnalités essentielles.
Simple à utiliser → SlyOS propose un programme d’accueil accessible depuis l’environnement live ou après l’installation. Il permet notamment de découvrir les principaux raccourcis et les outils disponibles. Le système peut également être utilisé sans passer par la ligne de commande grâce à Pamac, le gestionnaire de logiciels issu de Manjaro. Ce dernier est toutefois intégré à un système globalement beaucoup plus lourd que SlyOS.
Personnalisable → SlyOS s’appuie sur différents outils de personnalisation pour Wayland, comme Ironbar, Wofi, Hyprlock ou Vibepanel. Ils permettent d’obtenir un environnement de bureau suffisamment complet tout en laissant une grande liberté de modification. Il est possible de désinstaller ces outils et de les remplacer par d’autres alternatives. Le choix de niri facilite également cette personnalisation, puisque le gestionnaire de fenêtres est conçu pour être configuré en profondeur.
Performant → SlyOS utilise le noyau linux-cachyos, dans sa variante LTS, afin de bénéficier d’un bon compromis entre performances et stabilité. Le système consomme également peu de mémoire vive au démarrage grâce à l’utilisation d’OpenRC, de niri et d’un nombre limité de programmes. L’objectif est de proposer un bureau suffisamment complet pour un usage quotidien, sans multiplier les services exécutés en arrière-plan.
KISS → SlyOS utilise OpenRC, un gestionnaire de services qui suit une approche plus modulaire et plus proche du principe KISS que systemd. Ce dernier est régulièrement critiqué pour l’étendue de ses fonctionnalités, son poids et la complexité qu’il peut introduire dans le système. Ce choix ne signifie pas que systemd est inutilisable, mais simplement qu’OpenRC correspond davantage à la philosophie que je souhaite suivre avec SlyOS.
Intuitif → SlyOS présente les principaux raccourcis dès l’ouverture de l’environnement live ou après l’installation. Son bureau minimal, ainsi que l’accès aux paramètres et aux logiciels sans obligation d’utiliser la ligne de commande, doivent permettre à un utilisateur débutant de prendre rapidement le système en main. C’est toutefois un aspect qui se juge surtout à l’utilisation, et pas uniquement à partir de la liste des logiciels installés.
Je comprends également que l’explication est plus facile à suivre dans un commentaire que sur un site web. Cependant, j’ai aussi d’autres contraintes et je ne peux pas rédiger un long texte explicatif pour chaque échange, d’autant plus que je prévois de publier une dépêche consacrée au projet. Le meilleur moyen de se faire une opinion reste donc de tester SlyOS, par exemple dans une machine virtuelle.
La philosophie d’une distribution se manifeste d’abord par les choix logiciels qui la composent. C’est pour cette raison que je présente ces différents composants : ils permettent de comprendre concrètement la direction prise par SlyOS.
Concernant la remarque sur les concepts « flous » ou consensuels, je ne suis pas opposé à l’idée de présenter plus directement ce qui distingue SlyOS. Chaque concept est cependant associé à des choix précis, qui sont déjà expliqués dans les principes du projet et illustrés dans la galerie. Le caractère intuitif est plus difficile à résumer par la présence d’un logiciel particulier, puisqu’il dépend surtout de l’expérience d’utilisation.
Pour le point concernant le logiciel libre qui devient payant, ma position concerne principalement le modèle économique de Qt. Je ne reproche pas à un projet libre de chercher à se financer. Ce qui me dérange davantage, c’est que Qt repose notamment sur les revenus provenant de logiciels propriétaires et de licences commerciales. Je préfère donc soutenir des projets qui privilégient d’autres modèles, comme les dons, à l’image de ce qui existe autour de GTK.
Ma position peut paraître controversée, notamment parce que l’écosystème Linux dépend lui aussi largement de grandes entreprises, y compris Microsoft. Je ne prétends donc pas pouvoir éviter toute dépendance de ce type, mais j’essaie, autant que possible, de privilégier des logiciels et des projets capables de subsister sans être directement financés par le logiciel propriétaire.
Enfin, concernant la vie privée, remplacer systemd par OpenRC ne constitue évidemment pas, à lui seul, une garantie de meilleure confidentialité. Ce choix répond surtout à trois objectifs : éviter de renforcer la position dominante de systemd, utiliser un composant plus léger et rester plus proche du principe KISS.
Je considère néanmoins qu’OpenRC offre une approche plus prévisible et plus limitée dans son périmètre. Les inquiétudes récentes autour de l’ajout d’un champ
birthDatedans les données utilisateur de systemd illustrent la raison pour laquelle je préfère limiter les composants centraux aux fonctions dont le système a réellement besoin. Le problème n’est pas uniquement l’existence de ce champ, qui peut être présenté comme optionnel, mais aussi le fait que systemd puisse devenir un point central pour intégrer ce type de mécanisme à l’avenir.Je ne prétends pas qu’OpenRC garantit une meilleure confidentialité sur tous les plans. Je dis simplement que son périmètre plus restreint et son fonctionnement plus modulaire correspondent davantage au niveau de contrôle que je souhaite conserver dans SlyOS.