Je crois que ça n'a pas du tout le même genre d'utilité que les containers. J'ai l'impression que c'est plus fais pour étendre un système immutable comme Fedora Silverblue via des services utilisant des images disques dédiées et indépendantes du système de base.
La partie « So, what is a “Portable Service”? » commence par :
A portable service is ultimately just an OS tree, either inside of a directory, or inside a raw disk image containing a Linux file system. This tree is called the “image”. It can be “attached” or “detached” from the system. When “attached”, specific systemd units from the image are made available on the host system, then behaving pretty much exactly like locally installed system services. When “detached”, these units are removed again from the host, leaving no artifacts around (except maybe messages they might have logged).
La partie suivante, « Where’s the difference to a “Container”? » a ce second paragraphe :
“Portable services” do not provide a fully isolated environment to the payload, like containers mostly intend to. Instead, they are more like regular system services, can be controlled with the same tools, are exposed the same way in all infrastructure, and so on. The main difference is that they use a different root directory than the rest of the system. Hence, the intent is not to run code in a different, isolated environment from the host — like most containers would — but to run it in the same environment, but with stricter access controls on what the service can see and do.
De mon point de vue, pour l'instant, c'est toujours plus de complexité et un point de plus pour systemd qui veut tout faire…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
J'aime beaucoup systemd-nspawn, ça ressemble à s'y méprendre à un chroot. C'est génial pour gérer de la haute disponibilité et pour déployer : pas besoin de créer une image Docker et de la déployer à chaque modifications, on peut directement intervenir dans l'arborescence du container. On peut mettre à jour la production de manière totalement transparente, sans déployer des moyens lourds pour faire pas grand chose.
Je préfère également le bash à la syntaxe des Dockerfiles.
Je ne suis pas un grand expert en containeurisation mais depuis que j'ai découvert systemd-nspawn, ça a relégué Docker au rang de technologie des dinosaures pour moi.
L'écosystème Docker est effectivement gigantesque mais l'écosystème systemd-nspawn… c'est l'écosystème Linux tout entier ;).
Dans mon utilisation relativement basique (ci pour déploiement de wars sur tomcat 8), c'est vraiment plus agréable d'utiliser systemd-nspawn que Docker. Enfait juste une tâche CRON avec un git pull, build du projet, et un cp du résultat du build au bon endroit et c'est terminé. Difficile de faire plus simple.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
Posté par Nibel .
Évalué à 6.
Dernière modification le 24 septembre 2021 à 11:54.
Oui et non. systemd-nspawn nous laisse le choix.
On peut mettre le container en readonly si on veut profiter de l'immutabilité et s'amuser à recréer un container pour chaque déploiement (à la manière de ce qu'on fait sur Docker).
C'est juste que c'est un flux de travail qui ne me convient pas. Recréer un container quand je veux juste changer un CSS, c'est inutilement lourd.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
C'est pour le moment assez peu déployé, beaucoup de container tourne encore avec l'api CGroupV1 car pas mal de fonctionnalités intéressantes ne sont disponible que dans des versions récentes de systemd et du kernel donc comme toujours avant de retrouver ça en production ça va prendre des années (à moins que tu gère ta propre distrib/bsp).
La solution n'est pas encore parfaite, mais en soit, la voie est là. System-nspawn n'a qu'un support partiel de la spécification OCI et ce n'est pas une priorité des développeurs systemd de l'améliorer. En meme temps, il est logique que l'init gère les Cgroups (encore plus avec l'api V2 qui est hiérarchique). Donc le combo RunC qui parle à systemd via dbus est vraiment la bonne solution pour avoir la meilleur intégration je trouve.
Je crois que l'idée du portable service c'est d'être à mi-chemin entre systemd-nspawn et podman. En gros tu peux distribuer l'appli sous forme d'image disque (comme pour docker/podman/etc) sans aller jusqu'au niveau des outils de containerisation avec layering d'images, gestion des ports à ouvrir/publier, réseau interne, etc.
Est-ce que c'est essentiel quand on a déjà podman ou systemd-nspawn. Je ne pense pas. Est-ce que ça peut être utile. Certainement.
J'ai commencé à utiliser Linux en 2003 environ et j'ai adoré. Depuis ces quelques années je ne fais que détester ce que les développeurs (surtout RedHat et freedesktop) sont entrain de faire. flatpak, snaps (en plus j'ai testé Ubuntu 21.04 par curiosité, instabilité extrême) et containeurs à tout va. Il n'y a plus aucune simplicité (ne parlons pas de Alsa/PulseAudio/Pipewire/Jack car on aura pas fini), parce que l'espace disque est maintenant moins cher on se permet de copier toutes les fonctionnalités de Microsoft Windows et macOS pour les retranscrire sur Linux.
Ainsi, pour lancer une calculette on embarque ses dépendances à ses côtés. J'ose pas imaginer le désastre quand true, false, yes seront aussi containerisés, j'aurais plus qu'à faire portablectl yes, portablectl systemd-networkd.
git is great because linus did it, mercurial is better because he didn't
Bah peut-être parce que ce genre de commentaires est justement un truc de réac’.
Sérieux je veux bien que tout le monde donne son avis, mais vous avez vu le niveau d’argumentation déployé ici ?
Y’a une nouvelle feature qu’est développée dans systemd, il me faut 4 lectures de l’article de blog pour comprendre les tenants et les aboutissants du truc. On voit bien que c’est une feature satellite à systemd qui donne simplement des outils supplémentaires. Je me trompe peut-être mais ça semble clairement pas viser le desktop.
Et là on se coltine sur Linuxfr le même genre de posts totalement inutiles depuis 2010 qui contient toutes les frustrations de l’OS dans une mixture imbuvable. C’est quoi l’intérêt de parler de PulseAudio ici ? Mais quel rapport ? oO La comparaison avec MacOS/Windows, juste wtf vous êtes complètement hors-sujets là ! Je passe le troll sur yes/true…
Si vous voulez répéter vos mêmes complaintes (parce que très honnêtement y’a moyen de trouver une checksum qui match en 10 ans…) amusez-vous à écrire un journal ça nous changera.
Si vous voulez répéter vos mêmes complaintes (parce que très honnêtement y’a moyen de trouver une checksum qui match en 10 ans…) amusez-vous à écrire un journal ça nous changera.
Le problème, c'est que quand quelqu'un fait un journal sur devuan par exemple, qui prouve que ceux qui ne veulent pas du "progrès" peuvent s'en passer et se démerder seuls, tous ceux qui sont à l'opposé des «réacs» (les «fanboys» j'imagine?) et tous ceux qui considèrent que si c'est nouveau faut adopter se liguent pour le descendre en flammes, avec des commentaires tout aussi désobligeants voire pire que celui auquel tu réponds (de façon plus désobligeante que lui, d'ailleurs).
Je crois que ce qui fait que les gens descendent en flamme Devuan, c'est parce que Debian permet toujours de choisir son init et que Devuan ne s'est pas débarassé de libsystemd0.
Du coup ça a été beaucoup de grandes annonces pour absolument rien du tout.
Pas pour rien, puisque de fait, il y a eu depuis (combien de temps, je ne sais pas) une organisation et un travail en commun qui s'est mise en place entre ces deux distros sur le sujet de la diversité des init, et je pense sincèrement que l'absence d'un fork qui fonctionne aurait mené à la suppression pure et simple de l'alternative sysVinit dans debian à court terme.
Ça fait 4 ans maintenant que devuan existe, et a prouvé que les gens qui le font n'ont pas que de la gueule, mais peuvent aussi maintenir un système en vie.
Je pense que, sans devuan, les chances que sysvinit-core n'existerait plus
aujourd’hui comme (la seule, bien qu'il existe d'autres init packagés, il requièrent de faire tout le boulot) alternative à systemd-init pour init sont très élevées.
Pour ce qui est de libsystemd0… bon, c'est du foutage de gueule la, tous les pro-systemd ont toujours dit que ce n'était qu'un simple wrapper, que ça n'implique donc absolument pas systemd.
Maintenant qu'une distro sans systemd par défaut ne l'enlève pas, ça fait soudainement partie de systemd?
Une différence en pratique? Ben, une distro sans systemd, elle n'aura pas la tétrachiée d'utilisateurs et groupes créés par systemd par défaut.
Elle ne tentera pas d'installer systemd à chaque fois qu'un paquet cherche à installer dbus qui n'est pas encore installé.
Elle fera des efforts d'intégration pour les paquets.
C'est tout ça, le boulot d'une distro. De chercher a ce que les choix par défaut de la distro s'intègrent harmonieusement, et pas de brider les choix.
Le choix par défaut de devuan, c'est de ne pas avoir systemd. Ça implique très certainement pas mal de boulot, notamment autour de gnome a ce que j'ai lu.
J'en vois 4 (une pour chaque release + un troll + un compte créé pour écrire des liens pourris, la nimage est morte, pas moyen de ravoir tout le contexte sans réfléchir plus). Je ne vois pas non plus beaucoup d'activité sur debian elle-même, sauf bien sûr à l'approche des sorties de version.
Pour des distro bisannuelles, qui misent sur la stabilité de leurs systèmes avant tout, je ne suis pas choqué qu'il n'y ait pas tant de bruit.
Et pourtant, rien de ce que tu décris.
Pas de réactions désobligeantes de fanboys / pro-systemd (ton vocabulaire).
Pas de descente en flamme. Pas de ligues.
Parce qu’en vrai on s’en fiche complètement de systemd 364j sur 365. Mais bon chacun ses vendettas hein.
Posté par freem .
Évalué à 4.
Dernière modification le 24 septembre 2021 à 12:28.
Je ne comprend pas le problème… tu n'aimes pas le fait qu'il soit possible de faire des choses capilotractées avec un noyau linux?
Il reste toujours des distro qui évitent ce genre de trucs comme la peste, je pense notamment à kiss, et même de manière générale, personne ne t'impose d'utiliser ces choses.
Il y a même des distros mainstream (debian) qui te permettent de ne pas utiliser les nouvelles technos (elles vont t'y encourager, mais t'as le choix, et c'est ça, l'important).
Si je prend mon exemple:
flatpak, snaps (en plus j'ai testé Ubuntu 21.04 par curiosité, instabilité extrême) et containeurs à tout va.
J'utilise pas, et mon système satisfait largement mes besoins (CAO, dev, joujou avec le système, jeux, web, mater des vidéos, écouter des webradio, etc).
Il n'y a plus aucune simplicité (ne parlons pas de Alsa/PulseAudio/Pipewire/Jack car on aura pas fini),
PulseAudio, Pipewire et Jack se basent sur Alsa pour faire quoique ce soit. Ces surcouches ne sont absolument pas nécessaires pour avoir plusieurs applications qui jouent du son ou des vidéos en même temps, de mon expérience personnelle.
Je le sais, puisque je n'installe aucune de ces surcouches, et ce sont des choses que je fais régulièrement (avoir plusieurs sources sonores et vidéo).
Le seul truc qui requiert PA sur mes machines, et qui est la raison pour laquelle j'ai un dual-boot exprès avec systemd+dbus+PA, c'est firefox quand il faut faire de la webconf.
À revérifier, mais je crois qu'en plus, c'est uniquement firefox, pas les navigateurs basés sur blink (vivaldi, chromium, etc), et pour webkit, je ne sais pas. Je revérifierai la prochaine fois que j'ai besoin. D'un autre côté, je considère le web comme l'opposé exacte d'une technologie saine, en bonne santé, facile à maintenir, etc etc. J'en voudrais pour preuve qu'il n'existe que 3 moteurs de rendus potables, et le 3ème descend directement du 2nd: même les gros (opera?, microsoft) ont lâché l'affaire de maintenir ce genre d'horreur, c'est dire.
En fait, dans les environnements modernes, il est possible, en effet, de faire du super-complexe. Ça a peut-être même une utilité, je ne sais pas. Mais il est tout aussi possible de faire du simple dans de très nombreux cas.
Personnellement, je pense que mon système basé sur runit, avec mon gestionnaire de fenêtre et sa collection d'outils choisis en fonction de mes desiderata ( fonctionnalité requises, investissement en temps requis, poids en RAM et stockage minimaux juste parce que, indépendance au réseau au maximum (merci à celui qui a mentionné kiwix récemment d'ailleurs), dépendances sous contrôle pour tendre vers un système qui aie un nombre raisonnable de paquets, etc) est un système simple.
Enfin, simple… en fait, j'aimerai remplacer PAM (par BSDauth j'imagine?), voire même me débarasser d'initrd. Ho, et udev, aussi. Si j'arrivais a valider ces 3 points (tout en gardant un système fonctionnel), je pense que je pourrais réellement prétendre que mon système est simple et que je le maîtrise, mais bon, ça requiert un peu plus de boulot que de simplement sélectionner des paquets dans aptitude (encore que, pour udev, c'est faux, je pourrais utiliser busybox mdev, en vrai c'est surtout une question de flemme).
Qu'il soit possible de faire des choses de manière hyper complexe ne me pose aucun souci tant que ça n'impacte pas la possibilité de faire les choses simplement. Je suis du coup curieux de savoir en quoi ça te pose un problème (je me répète, je sais)?
Le seul truc qui requiert PA sur mes machines, et qui est la raison pour laquelle j'ai un dual-boot exprès avec systemd+dbus+PA, c'est firefox quand il faut faire de la webconf.Le seul truc qui requiert PA sur mes machines, et qui est la raison pour laquelle j'ai un dual-boot exprès avec systemd+dbus+PA, c'est firefox quand il faut faire de la webconf.
regarde un peu du coté de apulse : j'ai l'intuition qu'un apt install apulse couplé à un alias firefox="apulse firefox" te permettra de te débarrasser de ton dualboot.
Le cas de Firefox est un peu différent car ce n'est pas le binaire "firefox" qui se charge du son mais sa bibliothèque libxul.
Il faut utiliser la commande "patchelf" :
Placez vous dans le répertoire où est libxul.so. Sur ma Debian Buster/Testing, c'est dans "/usr/lib/firefox-esr/libxul.so".
cd /usr/lib/firefox-esr
sudo patchelf --set-rpath /usr/lib/apulse libxul.so
Puis pour lancer Firefox :
apulse firefox-esr
j'utilise la distribution binaire disponible sur le site de mozilla, et je n'ai pas eu besoin de faire appel à patchelf sur libxul.so .
Mais c'est peut être différent avec la version esr distribuée par debian.
Bon, je me débarrasserais pas pour autant du dual boot, parce que j'aime avoir un système de secours au cas ou je flingue ma distro (quand on bricole, ça arrive). Mais ça rendra justement ce système de secours plus fiable (moins utilisé, moins de risque de dommages).
Posté par Psychofox (Mastodon) .
Évalué à 5.
Dernière modification le 24 septembre 2021 à 12:30.
Je ne suis pas fans de tous les choix effectués (et pour moi l'ecosystème flatpak est une horreur par exemple même si une partie des concepts est intéressante), mais les technos que tu cites apportent une plus-value et un comfort à l'usage d'une utilisateur et aucune n'est obligatoire.
Tu peux toujours avoir une distro sans systemd/flatpak/snaps/pulseaudio/pipewire/jack si tu aimes la simplicité et la rusticité (sans compter qu'au bout du couloir openbsd et netbsd t'attendent à bras ouverts).
Tu peux toujours avoir une distro sans systemd/flatpak/snaps/pulseaudio/pipewire/jack si tu aimes la simplicité et la rusticité (sans compter qu'au bout du couloir openbsd et netbsd t'attendent à bras ouverts).
Cela est possible que si les applications décident de ne pas faire un prérequis. Par exemple il existe des applications qui dépendent strictement de pulseaudio ou udev (certains préfèrent mdev, plus simple). Donc tôt ou tard on se prend quand même des choses que l'on souhaite pas.
Pour le cas de PulseAudio je n'ai aucun problème avec, ça juste marche et je suis content que mon laptop change automatiquement de carte son quand je branche mon dock. Par contre, je suis moins content qu'après tant d'années à rendre PulseAudio stable on ait décidé d'implémenter un énième serveur de son.
git is great because linus did it, mercurial is better because he didn't
Cela est possible que si les applications décident de ne pas faire un prérequis. Par exemple il existe des applications qui dépendent strictement de pulseaudio ou udev (certains préfèrent mdev, plus simple).
Applications que tu peux choisir de ne pas utiliser pour préférer une alternative. Quand quelqu'un passe de windows à macos X ou linux il ne doit pas s'attendre forcément à utiliser les mêmes applications. Même chose ici. Et franchement dans le nombre du libre on a un nombre énorme d'alternatives pour réaliser les mêmes tâches.
Par contre, je suis moins content qu'après tant d'années à rendre PulseAudio stable on ait décidé d'implémenter un énième serveur de son.
Pipewire ne fait pas que l'audio et aide grandement lorsque l'on vit dans un environnement wayland, la raison est là. Et la transition pulseaudio-->pipewire est totalement transparente car les devs de pipewire ont été suffisemment intelligent pour travailler avec les devs de pulseaudio.
Par exemple il existe des applications qui dépendent strictement de pulseaudio ou udev (certains préfèrent mdev, plus simple).
C'est vrai.
J'ai cité FF qui requiert PA pour la webconf par exemple (mais juste la webconf, l'usage du micro en fait), mais comme je l'ai dit, il me semble aussi qu'il existe des alternatives (à vérifier) même si elles ne plaisent pas à tous (chromium ;) sur lequel skype est basé, et, oui, ça marche toujours sans PA/systemd/dbus, contrairement à FF, même si çapucpaslibr).
Pour dbus, j'en connais qui crashent quand il tourne pas, en général les recompiler sans le support dbus fait le taf (je n'ai pas encore rencontré le cas inverse, mais j'ai pas essayé pour xsane).
Pour udev, je suis curieux par contre, je n'en ai vue aucune. Des exemples?
Idem pour PA, dbus, systemd-logind (qui a elogind en alternative).
Somme toute, même si je suis d'accord avec toi pour l'idée que tout deviens potentiellement inutilement complexe, je ne te rejoins pas sur l'idée que c'est mal: après tout, ça reste purement potentiel.
Après, comme il est dit, quand tu fais le choix de ne pas utiliser certains pré-requis, il faut aller au bout de ses choix: tu peux patcher le code, tu peux aussi payer quelqu'un pour le faire (très grosse différence comparé aux mondes MS/MacOS), et surtout, et c'est ce que je fais la plupart du temps je l'avoue sans honte, utiliser un autre outil qui ait moins de dépendances.
En plus, un outil avec moins de dépendances, c'est moins de risque qu'il pète lorsqu'une dépendance lâche ou n'est plus maintenue (zenmap disparu de debian 11 est un bel exemple), et régulièrement plus de facilité à le patcher quand tu trouves un bug (moins de risque que ça soit dans une dépendance et donc de déclencher du debug recursif pendant perpette).
# use case
Posté par Psychofox (Mastodon) . Évalué à 7.
Je crois que ça n'a pas du tout le même genre d'utilité que les containers. J'ai l'impression que c'est plus fais pour étendre un système immutable comme Fedora Silverblue via des services utilisant des images disques dédiées et indépendantes du système de base.
[^] # Re: use case
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
La partie « So, what is a “Portable Service”? » commence par :
La partie suivante, « Where’s the difference to a “Container”? » a ce second paragraphe :
De mon point de vue, pour l'instant, c'est toujours plus de complexité et un point de plus pour systemd qui veut tout faire…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: use case
Posté par Nibel . Évalué à 8.
Systemd a déjà un outil de conteneurisation : systemd-nspawn.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: use case
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Je suis mitigé< sur ces apports de systemd:
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: use case
Posté par Nibel . Évalué à 8.
J'aime beaucoup systemd-nspawn, ça ressemble à s'y méprendre à un chroot. C'est génial pour gérer de la haute disponibilité et pour déployer : pas besoin de créer une image Docker et de la déployer à chaque modifications, on peut directement intervenir dans l'arborescence du container. On peut mettre à jour la production de manière totalement transparente, sans déployer des moyens lourds pour faire pas grand chose.
Je préfère également le bash à la syntaxe des Dockerfiles.
Je ne suis pas un grand expert en containeurisation mais depuis que j'ai découvert systemd-nspawn, ça a relégué Docker au rang de technologie des dinosaures pour moi.
L'écosystème Docker est effectivement gigantesque mais l'écosystème systemd-nspawn… c'est l'écosystème Linux tout entier ;).
Dans mon utilisation relativement basique (ci pour déploiement de wars sur tomcat 8), c'est vraiment plus agréable d'utiliser systemd-nspawn que Docker. Enfait juste une tâche CRON avec un git pull, build du projet, et un cp du résultat du build au bon endroit et c'est terminé. Difficile de faire plus simple.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: use case
Posté par claudex . Évalué à 7.
Ça retire un gros avantage des conteneurs à la Docker qui est l'immutabilité.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: use case
Posté par Nibel . Évalué à 6. Dernière modification le 24 septembre 2021 à 11:54.
Oui et non. systemd-nspawn nous laisse le choix.
On peut mettre le container en readonly si on veut profiter de l'immutabilité et s'amuser à recréer un container pour chaque déploiement (à la manière de ce qu'on fait sur Docker).
C'est juste que c'est un flux de travail qui ne me convient pas. Recréer un container quand je veux juste changer un CSS, c'est inutilement lourd.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: use case
Posté par Tangi Colin . Évalué à 3.
Le débat "Intégration/utilité Docker par rapport à systemd" est un vieux débat qui n'est bientôt plus d'actualité je trouve.
Runc (le runtime utilisé entre autre par Docker) fournit depuis peu (beaucoup moins longtemps que lxc) un support de l'api kernel CgroupV2. Et pour cela, il peut déléguer la gestion des Cgroups (V2) à systemd via un appel Dbus.
Voir pour plus d'info : https://github.com/opencontainers/runc/blob/master/docs/cgroup-v2.md et https://github.com/opencontainers/runc/blob/master/docs/systemd.md
C'est pour le moment assez peu déployé, beaucoup de container tourne encore avec l'api CGroupV1 car pas mal de fonctionnalités intéressantes ne sont disponible que dans des versions récentes de systemd et du kernel donc comme toujours avant de retrouver ça en production ça va prendre des années (à moins que tu gère ta propre distrib/bsp).
La solution n'est pas encore parfaite, mais en soit, la voie est là. System-nspawn n'a qu'un support partiel de la spécification OCI et ce n'est pas une priorité des développeurs systemd de l'améliorer. En meme temps, il est logique que l'init gère les Cgroups (encore plus avec l'api V2 qui est hiérarchique). Donc le combo RunC qui parle à systemd via dbus est vraiment la bonne solution pour avoir la meilleur intégration je trouve.
[^] # Re: use case
Posté par Psychofox (Mastodon) . Évalué à 5.
Je crois que l'idée du portable service c'est d'être à mi-chemin entre systemd-nspawn et podman. En gros tu peux distribuer l'appli sous forme d'image disque (comme pour docker/podman/etc) sans aller jusqu'au niveau des outils de containerisation avec layering d'images, gestion des ports à ouvrir/publier, réseau interne, etc.
Est-ce que c'est essentiel quand on a déjà podman ou systemd-nspawn. Je ne pense pas. Est-ce que ça peut être utile. Certainement.
# chroot
Posté par Mimoza . Évalué à 2.
En gros c'est un chroot facilité ?
[^] # Re: chroot
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Non l'équivalent de ça serait plutôt systemd-nspawn comme évoqué dans d'autres commentaires.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Pour une fois que ce n'est pas une réécriture de Go vers Rust
Posté par woffer 🐧 . Évalué à 2.
mais cette fois-ci de Go (Docker) -> systemd-nspawn (C).
Ok, je sors :)
# Linux devient Windows et macOS
Posté par David Demelier (site web personnel) . Évalué à -7.
J'ai commencé à utiliser Linux en 2003 environ et j'ai adoré. Depuis ces quelques années je ne fais que détester ce que les développeurs (surtout RedHat et freedesktop) sont entrain de faire. flatpak, snaps (en plus j'ai testé Ubuntu 21.04 par curiosité, instabilité extrême) et containeurs à tout va. Il n'y a plus aucune simplicité (ne parlons pas de Alsa/PulseAudio/Pipewire/Jack car on aura pas fini), parce que l'espace disque est maintenant moins cher on se permet de copier toutes les fonctionnalités de Microsoft Windows et macOS pour les retranscrire sur Linux.
Ainsi, pour lancer une calculette on embarque ses dépendances à ses côtés. J'ose pas imaginer le désastre quand
true,false,yesseront aussi containerisés, j'aurais plus qu'à faireportablectl yes,portablectl systemd-networkd.git is great because linus did it, mercurial is better because he didn't
[^] # Re: Linux devient Windows et macOS
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à -4.
Attention, tu vas passer pour un pauvre vieux réac antisystemd. Perso, j'ai commencé à revenir à *BSD pour ma tranquillité d'esprit.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Linux devient Windows et macOS
Posté par Sacha Trémoureux (site web personnel) . Évalué à 10.
Bah peut-être parce que ce genre de commentaires est justement un truc de réac’.
Sérieux je veux bien que tout le monde donne son avis, mais vous avez vu le niveau d’argumentation déployé ici ?
Y’a une nouvelle feature qu’est développée dans systemd, il me faut 4 lectures de l’article de blog pour comprendre les tenants et les aboutissants du truc. On voit bien que c’est une feature satellite à systemd qui donne simplement des outils supplémentaires. Je me trompe peut-être mais ça semble clairement pas viser le desktop.
Et là on se coltine sur Linuxfr le même genre de posts totalement inutiles depuis 2010 qui contient toutes les frustrations de l’OS dans une mixture imbuvable. C’est quoi l’intérêt de parler de PulseAudio ici ? Mais quel rapport ? oO La comparaison avec MacOS/Windows, juste wtf vous êtes complètement hors-sujets là ! Je passe le troll sur yes/true…
Si vous voulez répéter vos mêmes complaintes (parce que très honnêtement y’a moyen de trouver une checksum qui match en 10 ans…) amusez-vous à écrire un journal ça nous changera.
[^] # Re: Linux devient Windows et macOS
Posté par freem . Évalué à 4.
Le problème, c'est que quand quelqu'un fait un journal sur devuan par exemple, qui prouve que ceux qui ne veulent pas du "progrès" peuvent s'en passer et se démerder seuls, tous ceux qui sont à l'opposé des «réacs» (les «fanboys» j'imagine?) et tous ceux qui considèrent que si c'est nouveau faut adopter se liguent pour le descendre en flammes, avec des commentaires tout aussi désobligeants voire pire que celui auquel tu réponds (de façon plus désobligeante que lui, d'ailleurs).
[^] # Re: Linux devient Windows et macOS
Posté par Psychofox (Mastodon) . Évalué à 5.
Je crois que ce qui fait que les gens descendent en flamme Devuan, c'est parce que Debian permet toujours de choisir son init et que Devuan ne s'est pas débarassé de libsystemd0.
Du coup ça a été beaucoup de grandes annonces pour absolument rien du tout.
[^] # Re: Linux devient Windows et macOS
Posté par freem . Évalué à 5.
Pas pour rien, puisque de fait, il y a eu depuis (combien de temps, je ne sais pas) une organisation et un travail en commun qui s'est mise en place entre ces deux distros sur le sujet de la diversité des init, et je pense sincèrement que l'absence d'un fork qui fonctionne aurait mené à la suppression pure et simple de l'alternative sysVinit dans debian à court terme.
Ça fait 4 ans maintenant que devuan existe, et a prouvé que les gens qui le font n'ont pas que de la gueule, mais peuvent aussi maintenir un système en vie.
Je pense que, sans devuan, les chances que
sysvinit-coren'existerait plusaujourd’hui comme (la seule, bien qu'il existe d'autres init packagés, il requièrent de faire tout le boulot) alternative à
systemd-initpourinitsont très élevées.Pour ce qui est de libsystemd0… bon, c'est du foutage de gueule la, tous les pro-systemd ont toujours dit que ce n'était qu'un simple wrapper, que ça n'implique donc absolument pas systemd.
Maintenant qu'une distro sans systemd par défaut ne l'enlève pas, ça fait soudainement partie de systemd?
Une différence en pratique? Ben, une distro sans systemd, elle n'aura pas la tétrachiée d'utilisateurs et groupes créés par systemd par défaut.
Elle ne tentera pas d'installer systemd à chaque fois qu'un paquet cherche à installer dbus qui n'est pas encore installé.
Elle fera des efforts d'intégration pour les paquets.
C'est tout ça, le boulot d'une distro. De chercher a ce que les choix par défaut de la distro s'intègrent harmonieusement, et pas de brider les choix.
Le choix par défaut de devuan, c'est de ne pas avoir systemd. Ça implique très certainement pas mal de boulot, notamment autour de gnome a ce que j'ai lu.
[^] # Re: Linux devient Windows et macOS
Posté par Sacha Trémoureux (site web personnel) . Évalué à 2.
Y’a quasi aucun post sur Devuan depuis 3-4 ans.
[^] # Re: Linux devient Windows et macOS
Posté par freem . Évalué à 4.
J'en vois 4 (une pour chaque release + un troll + un compte créé pour écrire des liens pourris, la nimage est morte, pas moyen de ravoir tout le contexte sans réfléchir plus). Je ne vois pas non plus beaucoup d'activité sur debian elle-même, sauf bien sûr à l'approche des sorties de version.
Pour des distro bisannuelles, qui misent sur la stabilité de leurs systèmes avant tout, je ne suis pas choqué qu'il n'y ait pas tant de bruit.
[^] # Re: Linux devient Windows et macOS
Posté par Sacha Trémoureux (site web personnel) . Évalué à 2.
Et pourtant, rien de ce que tu décris.
Pas de réactions désobligeantes de fanboys / pro-systemd (ton vocabulaire).
Pas de descente en flamme. Pas de ligues.
Parce qu’en vrai on s’en fiche complètement de systemd 364j sur 365. Mais bon chacun ses vendettas hein.
[^] # Re: Linux devient Windows et macOS
Posté par freem . Évalué à 2.
Boarf si on peut plus troller le dredi…
[^] # Re: Linux devient Windows et macOS
Posté par freem . Évalué à 4. Dernière modification le 24 septembre 2021 à 12:28.
Je ne comprend pas le problème… tu n'aimes pas le fait qu'il soit possible de faire des choses capilotractées avec un noyau linux?
Il reste toujours des distro qui évitent ce genre de trucs comme la peste, je pense notamment à kiss, et même de manière générale, personne ne t'impose d'utiliser ces choses.
Il y a même des distros mainstream (debian) qui te permettent de ne pas utiliser les nouvelles technos (elles vont t'y encourager, mais t'as le choix, et c'est ça, l'important).
Si je prend mon exemple:
J'utilise pas, et mon système satisfait largement mes besoins (CAO, dev, joujou avec le système, jeux, web, mater des vidéos, écouter des webradio, etc).
PulseAudio, Pipewire et Jack se basent sur Alsa pour faire quoique ce soit. Ces surcouches ne sont absolument pas nécessaires pour avoir plusieurs applications qui jouent du son ou des vidéos en même temps, de mon expérience personnelle.
Je le sais, puisque je n'installe aucune de ces surcouches, et ce sont des choses que je fais régulièrement (avoir plusieurs sources sonores et vidéo).
Le seul truc qui requiert PA sur mes machines, et qui est la raison pour laquelle j'ai un dual-boot exprès avec systemd+dbus+PA, c'est firefox quand il faut faire de la webconf.
À revérifier, mais je crois qu'en plus, c'est uniquement firefox, pas les navigateurs basés sur blink (vivaldi, chromium, etc), et pour webkit, je ne sais pas. Je revérifierai la prochaine fois que j'ai besoin. D'un autre côté, je considère le web comme l'opposé exacte d'une technologie saine, en bonne santé, facile à maintenir, etc etc. J'en voudrais pour preuve qu'il n'existe que 3 moteurs de rendus potables, et le 3ème descend directement du 2nd: même les gros (opera?, microsoft) ont lâché l'affaire de maintenir ce genre d'horreur, c'est dire.
En fait, dans les environnements modernes, il est possible, en effet, de faire du super-complexe. Ça a peut-être même une utilité, je ne sais pas. Mais il est tout aussi possible de faire du simple dans de très nombreux cas.
Personnellement, je pense que mon système basé sur runit, avec mon gestionnaire de fenêtre et sa collection d'outils choisis en fonction de mes desiderata ( fonctionnalité requises, investissement en temps requis, poids en RAM et stockage minimaux juste parce que, indépendance au réseau au maximum (merci à celui qui a mentionné kiwix récemment d'ailleurs), dépendances sous contrôle pour tendre vers un système qui aie un nombre raisonnable de paquets, etc) est un système simple.
Enfin, simple… en fait, j'aimerai remplacer PAM (par BSDauth j'imagine?), voire même me débarasser d'initrd. Ho, et udev, aussi. Si j'arrivais a valider ces 3 points (tout en gardant un système fonctionnel), je pense que je pourrais réellement prétendre que mon système est simple et que je le maîtrise, mais bon, ça requiert un peu plus de boulot que de simplement sélectionner des paquets dans aptitude (encore que, pour udev, c'est faux, je pourrais utiliser busybox mdev, en vrai c'est surtout une question de flemme).
Qu'il soit possible de faire des choses de manière hyper complexe ne me pose aucun souci tant que ça n'impacte pas la possibilité de faire les choses simplement. Je suis du coup curieux de savoir en quoi ça te pose un problème (je me répète, je sais)?
[^] # Re: Linux devient Windows et macOS
Posté par Anonyme . Évalué à 3.
regarde un peu du coté de apulse : j'ai l'intuition qu'un
apt install apulsecouplé à unalias firefox="apulse firefox"te permettra de te débarrasser de ton dualboot.[^] # Re: Linux devient Windows et macOS
Posté par Le Pnume . Évalué à 3.
Lu sur http://linuxmao.org/apulse
[^] # Re: Linux devient Windows et macOS
Posté par Anonyme . Évalué à 2.
j'utilise la distribution binaire disponible sur le site de mozilla, et je n'ai pas eu besoin de faire appel à patchelf sur libxul.so .
Mais c'est peut être différent avec la version esr distribuée par debian.
[^] # Re: Linux devient Windows et macOS
Posté par freem . Évalué à 2.
Merci, je regarderais.
Bon, je me débarrasserais pas pour autant du dual boot, parce que j'aime avoir un système de secours au cas ou je flingue ma distro (quand on bricole, ça arrive). Mais ça rendra justement ce système de secours plus fiable (moins utilisé, moins de risque de dommages).
[^] # Re: Linux devient Windows et macOS
Posté par Psychofox (Mastodon) . Évalué à 5. Dernière modification le 24 septembre 2021 à 12:30.
Je ne suis pas fans de tous les choix effectués (et pour moi l'ecosystème flatpak est une horreur par exemple même si une partie des concepts est intéressante), mais les technos que tu cites apportent une plus-value et un comfort à l'usage d'une utilisateur et aucune n'est obligatoire.
Tu peux toujours avoir une distro sans systemd/flatpak/snaps/pulseaudio/pipewire/jack si tu aimes la simplicité et la rusticité (sans compter qu'au bout du couloir openbsd et netbsd t'attendent à bras ouverts).
[^] # Re: Linux devient Windows et macOS
Posté par David Demelier (site web personnel) . Évalué à 3.
Cela est possible que si les applications décident de ne pas faire un prérequis. Par exemple il existe des applications qui dépendent strictement de pulseaudio ou udev (certains préfèrent mdev, plus simple). Donc tôt ou tard on se prend quand même des choses que l'on souhaite pas.
Pour le cas de PulseAudio je n'ai aucun problème avec, ça juste marche et je suis content que mon laptop change automatiquement de carte son quand je branche mon dock. Par contre, je suis moins content qu'après tant d'années à rendre PulseAudio stable on ait décidé d'implémenter un énième serveur de son.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Linux devient Windows et macOS
Posté par Psychofox (Mastodon) . Évalué à 5.
Applications que tu peux choisir de ne pas utiliser pour préférer une alternative. Quand quelqu'un passe de windows à macos X ou linux il ne doit pas s'attendre forcément à utiliser les mêmes applications. Même chose ici. Et franchement dans le nombre du libre on a un nombre énorme d'alternatives pour réaliser les mêmes tâches.
Pipewire ne fait pas que l'audio et aide grandement lorsque l'on vit dans un environnement wayland, la raison est là. Et la transition pulseaudio-->pipewire est totalement transparente car les devs de pipewire ont été suffisemment intelligent pour travailler avec les devs de pulseaudio.
Donc je dirais que c'est un faux problème.
[^] # Re: Linux devient Windows et macOS
Posté par freem . Évalué à 2.
C'est vrai.
J'ai cité FF qui requiert PA pour la webconf par exemple (mais juste la webconf, l'usage du micro en fait), mais comme je l'ai dit, il me semble aussi qu'il existe des alternatives (à vérifier) même si elles ne plaisent pas à tous (chromium ;) sur lequel skype est basé, et, oui, ça marche toujours sans PA/systemd/dbus, contrairement à FF, même si çapucpaslibr).
Pour dbus, j'en connais qui crashent quand il tourne pas, en général les recompiler sans le support dbus fait le taf (je n'ai pas encore rencontré le cas inverse, mais j'ai pas essayé pour xsane).
Pour udev, je suis curieux par contre, je n'en ai vue aucune. Des exemples?
Idem pour PA, dbus, systemd-logind (qui a elogind en alternative).
Somme toute, même si je suis d'accord avec toi pour l'idée que tout deviens potentiellement inutilement complexe, je ne te rejoins pas sur l'idée que c'est mal: après tout, ça reste purement potentiel.
Après, comme il est dit, quand tu fais le choix de ne pas utiliser certains pré-requis, il faut aller au bout de ses choix: tu peux patcher le code, tu peux aussi payer quelqu'un pour le faire (très grosse différence comparé aux mondes MS/MacOS), et surtout, et c'est ce que je fais la plupart du temps je l'avoue sans honte, utiliser un autre outil qui ait moins de dépendances.
En plus, un outil avec moins de dépendances, c'est moins de risque qu'il pète lorsqu'une dépendance lâche ou n'est plus maintenue (zenmap disparu de debian 11 est un bel exemple), et régulièrement plus de facilité à le patcher quand tu trouves un bug (moins de risque que ça soit dans une dépendance et donc de déclencher du debug recursif pendant perpette).
[^] # Re: Linux devient Windows et macOS
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
C'est pas forcément un problème :-) https://sta.li/
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.