• # use case

    Post√©¬†par¬† . √Č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¬† (site web personnel, Mastodon) . √Čvalu√©¬†√†¬†3.

      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

      • [^] # Re: use case

        Post√©¬†par¬† . √Č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¬† (site web personnel) . √Čvalu√©¬†√†¬†4.

          Je suis mitigé< sur ces apports de systemd:

          • √ßa a l'air plus simple et mieux int√©gr√© au syst√®me que Docker¬†;
          • mais l'√©cosyst√®me Docker est √©norme (CMB).

          Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

          • [^] # Re: use case

            Post√©¬†par¬† . √Č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¬† . √Čvalu√©¬†√†¬†7.

              on peut directement intervenir dans l'arborescence du container.

              Ç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¬† . √Čvalu√©¬†√†¬†6. Derni√®re modification le 24/09/21 √† 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¬† . √Č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¬† . √Č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¬† . √Čvalu√©¬†√†¬†2.

    En gros c'est un chroot facilité ?

    • [^] # Re: chroot

      Post√©¬†par¬† (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¬† . √Čvalu√©¬†√†¬†2.

    mais cette fois-ci de Go (Docker) -> systemd-nspawn (C).
    Ok, je sors :)

  • # Linux devient Windows et macOS

    Post√©¬†par¬† (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, 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

    • [^] # Re: Linux devient Windows et macOS

      Post√©¬†par¬† (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¬† (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¬† . √Čvalu√©¬†√†¬†4.

          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).

          • [^] # Re: Linux devient Windows et macOS

            Post√©¬†par¬† . √Č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¬† . √Č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-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.

          • [^] # Re: Linux devient Windows et macOS

            Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†2.

            Y’a quasi aucun post sur Devuan depuis 3-4 ans.

            • [^] # Re: Linux devient Windows et macOS

              Post√©¬†par¬† . √Č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¬† (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¬† . √Čvalu√©¬†√†¬†4. Derni√®re modification le 24/09/21 √† 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)?

      • [^] # Re: Linux devient Windows et macOS

        Post√©¬†par¬† . √Čvalu√©¬†√†¬†3.

        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.

        • [^] # Re: Linux devient Windows et macOS

          Post√©¬†par¬† . √Čvalu√©¬†√†¬†3.

          Lu sur http://linuxmao.org/apulse

          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

          • [^] # Re: Linux devient Windows et macOS

            Post√©¬†par¬† . √Č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¬† . √Č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¬† . √Čvalu√©¬†√†¬†5. Derni√®re modification le 24/09/21 √† 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¬† (site web personnel) . √Čvalu√©¬†√†¬†3.

        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

        • [^] # Re: Linux devient Windows et macOS

          Post√©¬†par¬† . √Čvalu√©¬†√†¬†5.

          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.

          Donc je dirais que c'est un faux problème.

        • [^] # Re: Linux devient Windows et macOS

          Post√©¬†par¬† . √Čvalu√©¬†√†¬†2.

          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).

    • [^] # Re: Linux devient Windows et macOS

      Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†4.

      pour lancer une calculette on embarque ses d√©pendances √† ses c√īt√©s

      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.