• # use case

    PostĂ© par (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 (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).

          Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board

          • [^] # 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 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 . É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 (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 . É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 (site web personnel) . É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.

    AI is a mental disorder

    • [^] # 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 (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 . É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 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)?

      • [^] # 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 (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 (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.

        AI is a mental disorder

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

          PostĂ© par (Mastodon) . É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/

      Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board

Suivre le flux des commentaires

Note : les commentaires appartiennent Ă  celles et ceux qui les ont postĂ©s. Nous n’en sommes pas responsables.