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 freem . En réponse au lien systemd portable services: parce que les conteneurs, c'est trop mainstream. É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).